Date: Mon, 19 Jan 2004 23:49:33 -0600 From: "Micheal Patterson" <micheal@tsgincorporated.com> To: "Ken Bolingbroke" <hacker@bolingbroke.com>, "fbsd_user" <fbsd_user@a1poweruser.com> Cc: freebsd-questions@freebsd.org Subject: Re: ipfw/nated stateful rules example Message-ID: <1d85e01c3df19$2fd63610$0201a8c0@dredster> References: <MIEPLLIBMLEEABPDBIEGAEDEFFAA.fbsd_user@a1poweruser.com> <20040119201738.B30318@fremont.bolingbroke.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Ken Bolingbroke" <hacker@bolingbroke.com> To: "fbsd_user" <fbsd_user@a1poweruser.com> Cc: <freebsd-questions@freebsd.org> Sent: Monday, January 19, 2004 10:28 PM Subject: RE: ipfw/nated stateful rules example > > On Mon, 19 Jan 2004, fbsd_user wrote: > > > That's a play on words. And still does not prove stateful rules work on > > the interface facing the public internet. There is no documentation that > > says keep-state and limit only works on the interface facing the private > > Lan network. And the implied meaning is they are to be used on the > > interface facing the public internet. > > I just jumped in the middle here, so I may be out of context. > > But, stateful rules don't play nice with NAT. Consider non-NAT, a public > IP address contacting an Internet address: > > 67.161.59.61 -> 66.218.71.91 > > A rule is created for 66.218.71.91 coming to 67.161.59.61. When > 66.218.71.91 replies, the stateful rule lets it in. This is good. > > > But consider NAT: > > 10.0.0.10 changed to 67.161.59.61 -> 66.218.71.91 > > If you do a keep-state before NAT, you have a rule to allow 66.218.71.91 > to 10.0.0.10, but the return incoming packet will be 66.218.71.91 -> > 67.161.59.61, so the rule doesn't match. > > If you do a keep-state after NAT, then you have a rule to allow > 66.218.71.91 to 67.161.59.61. The return incoming packet matches that > rule, but it accepts the packet and packet processing stops, so it's never > passed through NAT, and never makes it back to 10.0.0.10. > > > So as it stands now, I don't see that you can use stateful connections > with NAT, unless check-state is changed to allow a packet to be passed > through NAT. > > Ken Bolingbroke Ken, try this one. This is what I use here at home and it does indeed work: Launch NATD with natd -interface ep0 -s -m -u (Only RFC1918 packets get altered) ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check state #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state NAT keeps a seperate table of it's translations to provide a back channel. Traffic comes in, generates a dynamic ruleset, gets translated, heads out and creates the 2nd dynamic for the packet. You'll end up with something like this ipfw -d list <snip> ## Dynamic rules: 00040 4 692 (T 18, slot 215) <-> tcp, 68.12.xx.xx3777<-> 216.239.57.99 80 00031 35 20374 (T 10, slot 219) <-> udp, 192.168.1.3 4986<-> 198.247.231.41 27019 00031 3 216 (T 1, slot 483) <-> tcp, 192.168.1.1 22<-> 192.168.1.2 3574 00031 16 11902 (T 298, slot 752) <-> tcp, 192.168.1.2 3777<-> 216.239.57.99 80 Granted, you'll end up with a dual entry for each packet in stateful space, but it does work. Perhaps not as intended with a single match but you can use statful with NAT. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d85e01c3df19$2fd63610$0201a8c0>