Date: Thu, 30 Oct 2008 18:34:31 -0500 From: Jack Barnett <jackbarnett@gmail.com> To: mdh_lists@yahoo.com Cc: Jeremy Chadwick <koitsu@freebsd.org>, Freebsd questions <freebsd-questions@freebsd.org> Subject: Re: Firewalls in FreeBSD? Message-ID: <490A4487.8020101@gmail.com> In-Reply-To: <367168.61424.qm@web56806.mail.re3.yahoo.com> References: <367168.61424.qm@web56806.mail.re3.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, I had some progress with this last night. Basically what I do is:
in natd - redirect_port 1000 to 10000 to the internal windows box.
set ipfw to "open" file wall.
Obviously this isn't prefect - but gives some idea of what's going on.
What I'd like to do, is a) keep the nat redirects since that works
pretty well.
b) in ipfw, ONLY allow data back on these ports IF the windows box has
established the connection out first then deny everything else.
I tried this, but it didn't work for anything (tried 5-6 differant games):
${fwcmd} add allow tcp from any to any out via x10 setup keep-state
${fwcmd} add allow udp from any to any out via xl0 keep-state
${fwcmd} add allow icmp from any to any out via xl0 keep-state
${fwcmd} add 100 check-state
mdh wrote:
> --- On Wed, 10/29/08, Jeremy Chadwick <koitsu@FreeBSD.org> wrote:
>
>> From: Jeremy Chadwick <koitsu@FreeBSD.org>
>> Subject: Re: Firewalls in FreeBSD?
>> To: "Terry Sposato" <terry@sucked-in.com>
>> Cc: jackbarnett@gmail.com, "Polytropon" <freebsd@edvax.de>, "Freebsd questions" <freebsd-questions@freebsd.org>
>> Date: Wednesday, October 29, 2008, 11:25 PM
>> On Thu, Oct 30, 2008 at 01:36:58PM +1100, Terry Sposato
>> wrote:
>>
>>
>>> 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.
>>
>
> Does the game support IPv6? This may be a work-around for you, since you can get a relatively large chunk of IPs for free via any one of a number of tunnel brokers. If possible, ask your IP provider if they provide native IPv6 transport first. A few do, in North America and Europe, and a surprising lot do in Asia, especially Japan and South Korea. If you're on a North American consumer ISP, chances are a tunnel broker is your only option for v6 connectivity, however.
>
> If the game doesn't support IPv6, however, then you are likely stuck with playing with port forwarding from the public routable address, however. It stinks, so feel free to lobby your ISP, the game's designers, and any other involved parties, about supporting IPv6 connectivity.
>
> In essence, a problem like the one Mr. Chadwick is eluding to is one of the primary motivating forces behind the adoption of IPv6 to begin with.
>
> - mdh
>
>
>
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?490A4487.8020101>