Date: Thu, 30 Jan 2003 11:18:40 -0500 From: "JoeB" <barbish@a1poweruser.com> To: "Willie Viljoen" <will@unfoldings.net> Cc: <freebsd-ipfw@freebsd.org> Subject: RE: Error in ipfw manpage for stateful rules? Message-ID: <MIEPLLIBMLEEABPDBIEGCENODEAA.barbish@a1poweruser.com> In-Reply-To: <200301301630.19610.will@unfoldings.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Well I think you make my point for me very well by pointing out that net.inet.ip.fw.one_pass=0 and the NATD option -d are necessary to get it to function correctly. And I must again point out that no where are these additional keep-state requirements documented. This is the part that is missing from the documentation when talking about IPFW / NATD with keep-state rules. Where in the IPFW documentation is this stated, and shouldn't there be an example of this method included in FBSD? >Now, to make this work properly, you should force packets diverted to natd >and re-injected into the chain to continue, instead of just being passed on. >To do this, set the net.inet.ip.fw.one_pass sysctl to 0, by putting this in >/etc/sysctl.conf: > >net.inet.ip.fw.one_pass=0 Rules 10 & 20 in the below example are for your transparent squid proxy and can be deleted if I an not using squid proxy correct? And I must still point out that my statement is still true. That keep-state rules do not function correctly in IPFW/NATD. -----Original Message----- From: Willie Viljoen [mailto:will@phoenix.home.laserfence.net]On Behalf Of Willie Viljoen Sent: Thursday, January 30, 2003 9:30 AM To: barbish@a1poweruser.com Cc: freebsd-ipfw@freebsd.org Subject: Re: Error in ipfw manpage for stateful rules? On Thursday 30 January 2003 16:13, JoeB wrote: > That is not the only thing wrong with the example. > IPFW with NATD does not function with keep-state rules. It doesn't? That's an extremely inacurate statement. Perhaps you should reevaluate your configuration, I refer to this example, which is currently working on many production firewall/NAT machines with my clients and in my own offices, this example also has a transparent squid proxy, and assumes the system is using a PPP connection to the internet, but it can also be ethernet (or any other interface): <taken from: /etc/ipfw.conf> -f flush add 00010 skipto 00030 tcp from me to any 80 add 00020 fwd 127.0.0.1,3128 tcp from any to any 80 add 00030 divert natd tcp from any to any via ppp0 add 00040 check-state add 00050 allow ip from any to any out keep-state add 00060 allow ip from 192.168.0.0/24 to any out keep-state add 00070 allow icmp from any to any icmptypes 0,3,4,8,11,12,13,14 add 00080 reset tcp from any to me 113 add 00090 unreach port udp from any to any 33434-33523 add 65534 deny log ip from any to any This allows all traffic from the local machine (including localhost), and from the local network 192.168.0.*. It also forward packets via a properly configured transparent squid proxy. Needed ICMP packets are allowed through. and ident requests and traceroutes from the outside are deflected. All packets not deflected or let through are logged. Now, to make this work properly, you should force packets diverted to natd and reinjected into the chain to continue, instead of just being passed on. To do this, set the net.inet.ip.fw.one_pass sysctl to 0, by putting this in /etc/sysctl.conf: net.inet.ip.fw.one_pass=0 And, for the current session, at the command line: sysctl net.inet.ip.fw.one_pass=0 Now, launch natd as such. This assumes the PPP interface has a static IP (10.0.1.27). If it's a dynamic dial-up, start it from /etc/ppp/ip-up and use the -n switch instead. For this example, in /etc/rc.conf: natd_enable="YES" natd_flags="-d -s -m -u -a 10.0.1.27 -punch_fw 10000:10000" And from the command line, for the current session: /sbin/natd -d -s -m -u -a 10.0.1.27 -punch_fw 10000:10000 To start natd appropriately from /etc/ppp/ip-up: /sbin/natd -d -s -m -u -n ppp0 -punch_fw 10000:10000 Finally, you also need (obviously) these settings in /etc/rc.conf for this example to function properly: gateway_enable="YES" firewall_enable="YES" firewall_type="/etc/ipfw.conf" After all of this has been set up, all traffic passing through the NAT interface will be passed to natd. After the address translation has been done, it is passed back to the ipfw rule chain sothat other rules (including stateful rules) can inspect the packets. The -punch_fw 10000:10000 switch to natd tells natd that it may inject its own dynamic (stateful) rules into the firewall between rules 10000 and 20000. The -d switch sets natd to block any non-natted (unknown) connection passed to it. This example *DOES* work, so I do not see how you can claim that natd and ipfw stateful rules can not work together. Got my two cents Will > Just read the IPFW-list archives back through 1/2002 and you will > get a very clear picture of the problem. > Don't you think it's about time NATD gets fixed or you say some > thing in the examples about this problem. > Divorcing the built in divert natd rule from IPFW and making the NAT > function > a standalone function would be the simplest fix. > > > > -----Original Message----- > From: owner-freebsd-ipfw@FreeBSD.ORG > [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Nick Rogness > Sent: Wednesday, January 29, 2003 9:25 PM > To: Simon L. Nielsen > Cc: freebsd-ipfw@FreeBSD.ORG > Subject: Re: Error in ipfw manpage for stateful rules? > > On Wed, 29 Jan 2003, Simon L. Nielsen wrote: > > Hello > > > > The ipfw man page for stateful rules has two examples. Shouldn't > > the > > > allow rule have a keep-state keyword ? > > > > So > > > > ipfw add check-state > > ipfw add allow tcp from my-subnet to any setup > > ipfw add deny tcp from any to any > > > > is changed to > > > > ipfw add check-state > > ipfw add allow tcp from my-subnet to any setup keep-state > > ipfw add deny tcp from any to any > > > > And similar for udp. > > I just verified that you are correct. I wasn't sure if > setup > implied keep-state or not (don't know why it would). I just > typed > it in and you definetly need the keep-state keyword with the > rule. > > I did a quick search for this mentioned in the PR database > and > didn't find a match. Do a more thorough check and make sure > someone has not already submitted a PR for this, then > submit a PR. Or if not, I can. > > > Nick Rogness <nick@rogness.net> > - > How many people here have telekenetic powers? Raise my hand. > -Emo Philips > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message -- Willie Viljoen Freelance IT Consultant 214 Paul Kruger Avenue, Universitas Bloemfontein 9321 South Africa +27 51 522 15 60 +27 51 522 44 36 (after hours) +27 82 404 03 27 (mobile) will@unfoldings.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MIEPLLIBMLEEABPDBIEGCENODEAA.barbish>