Firewalls in FreeBSD?
Terry Sposato
terry at sucked-in.com
Wed Oct 29 21:20:08 PDT 2008
Quoting Jeremy Chadwick <koitsu at FreeBSD.org>:
> On Thu, Oct 30, 2008 at 01:36:58PM +1100, Terry Sposato wrote:
>> Quoting Jack Barnett <jackbarnett at gmail.com>:
>>
>>>
>>> yes, that is my setup.
>>> hrm... well, I disabled the firewall completely, restarted, but still
>>> doesn't work.
>>> I have gateway and natd both enabled. x10 is the "external" interface
>>> (the one that is dhcp and connects to the cable modem).
>>> I don't want to redirect anything to my windows box. I just want
>>> anything that connects out from my windows box to be able to connect
>>> or send data back in.
>>> For example, I load up a client (game) and it connects out on XYZ
>>> port. The server will send data back on ABC.
>>> The problem, from what I can tell; is that I can get a connection out
>>> - but when the server tries to send data back on ABC it is discarded.
>>> Polytropon wrote:
>>>
>>> If I understood you correctly, your setting is:
>>>
>>> (Modem/Router)---DHCP---(FreeBSD)---("Windows")
>>>
>>> I may respond directly on your configuration settings:
>>>
>>> On Wed, 29 Oct 2008 20:19:31 -0500, Jack Barnett
>>> [1]<jackbarnett at gmail.com> wro
>>> te:
>>>
>>>
>>> gateway_enable="YES"
>>> #firewall_enable="YES"
>>> #firewall_type="open"
>>> firewall_type="simple"
>>> #firewall_type="open"
>>> firewall_logging="YES"
>>>
>>>
>>> Use instead:
>>>
>>> gateway_enable="YES"
>>> natd_enable="YES"
>>> natd_interface="xl0"
>>>
>>> You may add special redirect directives to NATD's settings, such
>>> as
>>> natd_flags="-redirect_port tcp 192.168.1.2:5900 5900"
>>> natd_flags="-redirect_port tcp 192.168.1.5:23 6666"
>>>
>>> or
>>> natd_flags="-redirect_address 192.168.1.2 141.44.165.58 \
>>> -redirect_address 192.168.1.5 141.44.165.58"
>>>
>>> Examples taken from a very old configuration. :-)
>>>
>>> Then,
>>>
>>> firewall_enable="YES"
>>> firewall_type="/etc/ipfw.conf"
>>>
>>> Then, be sure to have nice firewall settings, you can use things
>>> similar to this, enabling just the services you really need and want,
>>> it's easy to write your own one or to rewrite this:
>>>
>>> -f flush
>>> add divert natd ip from any to any via xl0
>>> add allow tcp from any to any ftp in recv xl0
>>> add allow tcp from any to any ssh in recv xl0
>>> add allow tcp from any to any auth in recv xl0
>>> add allow udp from any to any ntp in recv xl0
>>> add allow udp from any to any ntalk in recv xl0
>>> add deny udp from any to any x11 in recv xl0
>>> add reset tcp from any to any x11 in recv xl0
>>> add allow ipencap from any to any
>>> add allow ip from any to any
>>>
>>> This should work fine. NB to use the correct interface names.
>>>
>>> References
>>>
>>> 1. mailto:jackbarnett at gmail.com
>>> _______________________________________________
>>> freebsd-questions at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>> To unsubscribe, send any mail to
>>> "freebsd-questions-unsubscribe at freebsd.org"
>>>
>>
>> Jack,
>>
>> It is most likely caused by your ruleset not being stateful. If packets
>> are going out certain sessions and your firewall isn't then allowing back
>> in you would see the issue you are seeing. I am not sure how this is
>> accomplished via ipfw as I use pf but there would be a tonne of
>> documentation out there on how to make your rules stateful.
>
> Are you sure about that? Read his statement once more:
>
>>> For example, I load up a client (game) and it connects out on XYZ
>>> port. The server will send data back on ABC.
Ahh yes correct, I was going on the assumption that the traffic is
trying to return using the same session details. This is usually how
it is with gaming traffic and the non stateful ruleset is usually the
cause of why this sort of traffic get's blocked. Would like to see if
the OP has actually sniffed the traffic and can say without a shadow
of a doubt that different ports are being used ingoing & outgoing.
>
> I assume based on this, the following is happening:
>
> - 192.168.x.x:aaaaa sends packet to gameserver:xyz
>
> - NAT gateway translates packet (where "natgw" is a public WAN IP)
>
> 192.168.x.x:aaaaa <--> natgw:bbbbb <--> gameserver:xyz
>
> - gameserver sees packet to port xyz, and initiates new connection
> to natgw:abc
>
> - NAT gateway drops packet destined to WAN IP port abc, because the
> gameserver:abc connection is *new*, and does not relate to the
> previous NAT'd gameserver:xyz connection.
>
> If this is **truly** how the protocol works (the OP will need to be
> absolutely 100% positive of that fact; I recommend he reconfirm how it
> works), then the only solution is to set up a port forward on the NAT
> gateway for port abc to point to 192.168.x.x.
>
> This also means that only one computer on the LAN will be capable of
> playing this game. Not much one can do about that, other than write
> the authors of the game and explain that their protocol is absolutely
> disgusting.
>
> --
> | Jeremy Chadwick jdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, USA |
> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>
Regards,
Terry Sposato
terry at sucked-in.com
Have you been sucked in?
http://www.sucked-in.com
-------------------------------------------------------------------------------------
This message was sent from the Sucked In Webmail Interface -
http://www.sucked-in.com
More information about the freebsd-questions
mailing list