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 <[EMAIL PROTECTED]> wrote:
From: Jeremy Chadwick <[EMAIL PROTECTED]>
Subject: Re: Firewalls in FreeBSD?
To: "Terry Sposato" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], "Polytropon" <[EMAIL PROTECTED]>, "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 "[EMAIL PROTECTED]"
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
