Re: Firewalls in FreeBSD?
On Fri, Oct 31, 2008 at 01:27:40PM -0400, Lowell Gilbert wrote: > Jeremy Chadwick <[EMAIL PROTECTED]> writes: > > > On Fri, Oct 31, 2008 at 12:35:30PM -0400, Lowell Gilbert wrote: > > >> Okay, I guess I'm a little confused by the line about "ONLY allow data > >> back on these ports IF the windows box has established the connection > >> out first then deny everything else." I read that as saying that the > >> Windows box had sent a packet on the same connection (4-tuple, at > >> least) that should be later accepted heading *to* the Windows box. > >> That's just a stateful rule, and it seems to be at odds with what you > >> wrote in your first message in the thread. The apparent disagreement > >> was why I said anything in the first place; it sounds like there's > >> more than one model of how the game works. > > > > I understand the confusion. Here's the actual protocol that the game > > appears to be using (since the OP has stated forwarding a port range to > > his LAN PC solves the problem -- meaning, his original description of > > how the game protocol worked is accurate): > > I see. If that is the case, then the word "connection" in the line I > quoted from Jack Barnett does *not* mean a TCP session, but something > a little more nebulous. "Game session" might cover it. > > [I *was* aware of that possible confusion, which was why I specified > an address/port tuple as the definition of "connection."] > > Sorry for the distraction; I see that (short of a deep-inspection > snooping of the protocol), what has already been done is as good as > you can get. Nah, it's cool -- the misunderstanding is... understandable. :-) I've never seen a game behave this way (specifically, the gameserver initiating a *brand new connection* rather than utilising an existing one, or having the client initiate a connection to the server -- in which case, a stateful firewall will work perfectly and no firewall rules are needed). -- | Jeremy Chadwickjdc 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
Jeremy Chadwick <[EMAIL PROTECTED]> writes: > On Fri, Oct 31, 2008 at 12:35:30PM -0400, Lowell Gilbert wrote: >> Okay, I guess I'm a little confused by the line about "ONLY allow data >> back on these ports IF the windows box has established the connection >> out first then deny everything else." I read that as saying that the >> Windows box had sent a packet on the same connection (4-tuple, at >> least) that should be later accepted heading *to* the Windows box. >> That's just a stateful rule, and it seems to be at odds with what you >> wrote in your first message in the thread. The apparent disagreement >> was why I said anything in the first place; it sounds like there's >> more than one model of how the game works. > > I understand the confusion. Here's the actual protocol that the game > appears to be using (since the OP has stated forwarding a port range to > his LAN PC solves the problem -- meaning, his original description of > how the game protocol worked is accurate): I see. If that is the case, then the word "connection" in the line I quoted from Jack Barnett does *not* mean a TCP session, but something a little more nebulous. "Game session" might cover it. [I *was* aware of that possible confusion, which was why I specified an address/port tuple as the definition of "connection."] Sorry for the distraction; I see that (short of a deep-inspection snooping of the protocol), what has already been done is as good as you can get. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
On Fri, Oct 31, 2008 at 12:35:30PM -0400, Lowell Gilbert wrote: > Jeremy Chadwick <[EMAIL PROTECTED]> writes: > > > On Fri, Oct 31, 2008 at 12:05:28PM -0400, Lowell Gilbert wrote: > >> Jeremy Chadwick <[EMAIL PROTECTED]> writes: > >> > >> > On Thu, Oct 30, 2008 at 06:34:31PM -0500, Jack Barnett wrote: > >> >> > >> >> Ok, I had some progress with this last night. Basically what I do is: > >> >> > >> >> in natd - redirect_port 1000 to 1 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. > >> > > >> > This is called "port triggering" in the residential router world. I > >> > don't know how to do this on FreeBSD. > >> > >> Stateful rules are the only way to do it. > >> In fact, this is the main purpose of stateful rules. > > > > Read this part of the thread, where I outline protocol flow (based on > > what the OP has stated about the protocol, which so far appears to be > > accurate): > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2008-October/thread.html > > > > Stateful rules will not solve this problem. > > > > The OP wants a feature that tells ipfw or pf "after the TCP handshake > > has completed, dynamically add a port forward for port X on interface Y > > to machine A on port Z; when the TCP session is FIN'd cleanly, or > > extinguishes, dynamically remove that port forward". > > Okay, I guess I'm a little confused by the line about "ONLY allow data > back on these ports IF the windows box has established the connection > out first then deny everything else." I read that as saying that the > Windows box had sent a packet on the same connection (4-tuple, at > least) that should be later accepted heading *to* the Windows box. > That's just a stateful rule, and it seems to be at odds with what you > wrote in your first message in the thread. The apparent disagreement > was why I said anything in the first place; it sounds like there's > more than one model of how the game works. I understand the confusion. Here's the actual protocol that the game appears to be using (since the OP has stated forwarding a port range to his LAN PC solves the problem -- meaning, his original description of how the game protocol worked is accurate): windows= 192.168.x.x machine on the LAN natgwlan = private LAN-facing IP of FreeBSD box (e.g. gateway IP) natgwwan = public Internet-facing IP of FreeBSD box gameserver = game server (public Internet IP) * = randomly-allocated port number gameport = some static port # for the game (OP hasn't disclosed this) range = some specific range of port numbers (OP says 1000-1) This is what would happen if the windows machine was on the Internet directly (no NAT, no firewall): Step 1) windows:* --> gameserver:gameport Step 2) gameserver:* --> windows:range Note that the randomly-allocated port number is *not* identical between all of the above steps; literally each is a new port and unrelated to the previous -- hence why state tracking won't work. Now with NAT in the way, this is what happens for Step 1: windows:* <--> natgwlan natgwwan:* <--> gameserver:gameport Once the TCP handshake is completed for Step 1, the following happens as a result of Step 2 -- again, note this is a *brand new connection* being initiated from the gameserver: gameserver:* <--> natgwwan:range The problem is that these are all brand new connections being initiated, and there's no way to cross-reference them, which is why state tracking won't work to solve the OPs problem. The "port triggering" method I described above, commonly available on residential routers, is configured so that once the TCP handshake is completed in Step 1, the router/natgw *immediately* adds a port forward and firewall allow/pass rule (you have to configure it to say what port range to forward, and what LAN IP to forward the packets to). Thus, the following would happen immediately after the TCP handshake was completed in Step 1: - natgw adds a firewall pass rule for natgwwan:range - natgw adds a forwarding rule for natgwwan:1000 --> windows, where the port number matches (e.g. natgwwan:1000 --> windows:1000) This pass/allow rule and the forward remains intact until the "port triggered" connection is severed (FIN or expired). It does not expire/close based upon the connection made in Step 1. This would allow Step to work, and would look like this with NAT in the way: gameserver:* <--> natgwwan:range natgwlan --> windows:range This is as verbose as I can get, and based upon the forwarding and the firewall rules the OP added, this does appear to be the protocol the
Re: Firewalls in FreeBSD?
Jeremy Chadwick <[EMAIL PROTECTED]> writes: > On Fri, Oct 31, 2008 at 12:05:28PM -0400, Lowell Gilbert wrote: >> Jeremy Chadwick <[EMAIL PROTECTED]> writes: >> >> > On Thu, Oct 30, 2008 at 06:34:31PM -0500, Jack Barnett wrote: >> >> >> >> Ok, I had some progress with this last night. Basically what I do is: >> >> >> >> in natd - redirect_port 1000 to 1 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. >> > >> > This is called "port triggering" in the residential router world. I >> > don't know how to do this on FreeBSD. >> >> Stateful rules are the only way to do it. >> In fact, this is the main purpose of stateful rules. > > Read this part of the thread, where I outline protocol flow (based on > what the OP has stated about the protocol, which so far appears to be > accurate): > > http://lists.freebsd.org/pipermail/freebsd-questions/2008-October/thread.html > > Stateful rules will not solve this problem. > > The OP wants a feature that tells ipfw or pf "after the TCP handshake > has completed, dynamically add a port forward for port X on interface Y > to machine A on port Z; when the TCP session is FIN'd cleanly, or > extinguishes, dynamically remove that port forward". Okay, I guess I'm a little confused by the line about "ONLY allow data back on these ports IF the windows box has established the connection out first then deny everything else." I read that as saying that the Windows box had sent a packet on the same connection (4-tuple, at least) that should be later accepted heading *to* the Windows box. That's just a stateful rule, and it seems to be at odds with what you wrote in your first message in the thread. The apparent disagreement was why I said anything in the first place; it sounds like there's more than one model of how the game works. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
On Fri, Oct 31, 2008 at 12:05:28PM -0400, Lowell Gilbert wrote: > Jeremy Chadwick <[EMAIL PROTECTED]> writes: > > > On Thu, Oct 30, 2008 at 06:34:31PM -0500, Jack Barnett wrote: > >> > >> Ok, I had some progress with this last night. Basically what I do is: > >> > >> in natd - redirect_port 1000 to 1 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. > > > > This is called "port triggering" in the residential router world. I > > don't know how to do this on FreeBSD. > > Stateful rules are the only way to do it. > In fact, this is the main purpose of stateful rules. Read this part of the thread, where I outline protocol flow (based on what the OP has stated about the protocol, which so far appears to be accurate): http://lists.freebsd.org/pipermail/freebsd-questions/2008-October/thread.html Stateful rules will not solve this problem. The OP wants a feature that tells ipfw or pf "after the TCP handshake has completed, dynamically add a port forward for port X on interface Y to machine A on port Z; when the TCP session is FIN'd cleanly, or extinguishes, dynamically remove that port forward". -- | Jeremy Chadwickjdc 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
Jeremy Chadwick <[EMAIL PROTECTED]> writes: > On Thu, Oct 30, 2008 at 06:34:31PM -0500, Jack Barnett wrote: >> >> Ok, I had some progress with this last night. Basically what I do is: >> >> in natd - redirect_port 1000 to 1 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. > > This is called "port triggering" in the residential router world. I > don't know how to do this on FreeBSD. Stateful rules are the only way to do it. In fact, this is the main purpose of stateful rules. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
On Thu, Oct 30, 2008 at 06:34:31PM -0500, Jack Barnett wrote: > > Ok, I had some progress with this last night. Basically what I do is: > > in natd - redirect_port 1000 to 1 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. This is called "port triggering" in the residential router world. I don't know how to do this on FreeBSD. -- | Jeremy Chadwickjdc 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
Ok, I had some progress with this last night. Basically what I do is:
in natd - redirect_port 1000 to 1 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"
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:a sends packet to gameserver:xyz
- NAT gateway translates packet (where "natgw" is
a public WAN IP)
192.168.x.x:a <--> natgw:b <-->
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]"
Re: Firewalls in FreeBSD?
--- 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" > > 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:a sends packet to gameserver:xyz > > - NAT gateway translates packet (where "natgw" is > a public WAN IP) > > 192.168.x.x:a <--> natgw:b <--> > 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]"
Re: Firewalls in FreeBSD?
Hi Jack! Right now I have a Windows machine a FreeBSD natd/firewall then a cable modem. This is working for web surfing. But I've been playing a lot of games lately and it doesn't work at all (for multiplayer/internet games). As a fellow gamer, I've found that PF with stateful filtering has been a good firewall for my needs. Usually with stateful ruleset the games work out of the box, just when outgoing traffic is allowed and state is kept. There are some special situations where PF shines though, Asherons Call (or any other game using bidirectional UDP traffic) can be made to work with following configuration: This to nat section: binat on $ext_if from to or IP> -> $ext_if Which should do the trick with some of the silly games out there using standard defined, but really rare kind of traffic. -Reko ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>:
On Thu, Oct 30, 2008 at 01:36:58PM +1100, Terry Sposato wrote:
Quoting Jack Barnett <[EMAIL PROTECTED]>:
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]<[EMAIL PROTECTED]> 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 "
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 authin 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 denyudp 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:[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
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:a sends packet to gameserver:xyz
- NAT gateway translates packet (where "natgw" is a public WAN IP)
192.168.x.x:a <--> natgw:b <--> 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 Chadwickjdc at parodius.com |
| Parodius Networking
Re: Firewalls in FreeBSD?
On Thu, Oct 30, 2008 at 01:36:58PM +1100, Terry Sposato wrote:
> Quoting Jack Barnett <[EMAIL PROTECTED]>:
>
>>
>>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]<[EMAIL PROTECTED]> 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 "
>>
>> 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 authin 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 denyudp 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:[EMAIL PROTECTED]
>> ___
>> freebsd-questions@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>>
>
> 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:a sends packet to gameserver:xyz
- NAT gateway translates packet (where "natgw" is a public WAN IP)
192.168.x.x:a <--> natgw:b <--> 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 Chadwickjdc 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 |
_
Re: Firewalls in FreeBSD?
Quoting Jack Barnett <[EMAIL PROTECTED]>:
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]<[EMAIL PROTECTED]> 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 "
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 authin 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 denyudp 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:[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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.
Regards,
Terry Sposato
[EMAIL PROTECTED]
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
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
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]<[EMAIL PROTECTED]> 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 "
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 authin 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 denyudp 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:[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firewalls in FreeBSD?
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 <[EMAIL PROTECTED]> wrote:
> 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 "
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 authin 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 denyudp 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.
--
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Firewalls in FreeBSD?
Right now I have a Windows machine a FreeBSD natd/firewall then a cable modem. This is working for web surfing. But I've been playing a lot of games lately and it doesn't work at all (for multiplayer/internet games). Basically the games send/receive data on random ports, and I think it's going out fine - but doesn't come back in. Is this a problem with nat or because I have a stateless firewall? I've played around with this on and off for the last while and haven't gotten any where with it. Do you think this would work better or at least be easier to configure/debug if I moved to pf instead? Do I need to run natd if I run pf? FreeBSD fire2 6.3-STABLE FreeBSD 6.3-STABLE #32: Tue Jan 22 22:21:30 CST 2008 gateway_enable="YES" #firewall_enable="YES" #firewall_type="open" firewall_type="simple" #firewall_type="open" firewall_logging="YES" ## PF #pf_enable="NO" # Enable PF (load module if required) #pf_rules="/etc/pf.conf" # rules definition file for pf #pf_flags="" # additional flags for pfctl startup #pflog_enable="YES" # start pflogd(8) #pflog_logfile="/var/log/pflog" # where pflogd should store the logfile #pflog_flags="" # additional flags for pflogd startup ## NATD natd_enable="YES" natd_interface="xl0" natd_flags=" -f /etc/natd.conf" ifconfig_xl0="DHCP" ifconfig_dc0="inet 192.168.17.1 netmask 255.255.255.0" ifconfig_dc1="inet 192.168.18.1 netmask 255.255.255.0" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
