Firewalls in FreeBSD?

[Jeremy Chadwick]

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.

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 |