Date: Thu, 23 Jun 2011 21:42:51 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: umage <theultramage@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: ipfw nat inbound keep-state with net.inet.ip.fw.one_pass=0 Message-ID: <20110623205741.K34951@sola.nimnet.asn.au> In-Reply-To: <20110621223335.2C145106579B@hub.freebsd.org> References: <20110621223335.2C145106579B@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 368, Issue 6, Message: 21 On Tue, 21 Jun 2011 20:16:32 +0200 umage <theultramage@gmail.com> wrote: > Hi, I'm an ipfw user that finally got the opportunity to set up NAT on > an interface with a public IP. I was doing some multi-homing experiments > using ipfw fwd combined with outbound ipfw nat - and since I needed to > run both, and both immediately ended ipfw ruleset execution, I had to > turn off net.inet.ip.fw.one_pass. > > This is where I discovered that with that setting turned off, my inbound > NAT rule stopped working. Seems that with one-pass execution, the NAT > rule also performs keep-state of some sort, the dynamic state table > looks ok and everything works fine. But if I turn it off, and do my own > "allow all in keep-state" after applying a static NAT rule on an inbound > connection, I see that the state table has the remote IP on the left > side and mine on the right side. I also see that my NAT setup breaks and > my packets are sent to the internet with a 192.168.0.x source address. It's not possible to tell what's going on from just such a description without sharing your ruleset with us. Offhand it smells like you may have your nat rule/s in the wrong place with respect to check-state or keep-state rule(s). If you show us your ruleset (with any sensitive addresses anonymised if need be) and network configuration, then your problem may become evident. On the face of it, 'allow all in keep-state' is a very dangerous rule, and I'd advise a comparison of your ruleset to the relevant section in /etc/rc.firewall. You should ignore the IPFW section in the Handbook, written by someone who prefers ipfilter and containing many errors; ipfw(8) is your friend. > I'd like to ask if I'm doing anything wrong, or whether this is a bug. I > checked the issue tracker, but found no relevant issues there. I also > tried asking around, but it seems noone even uses ipfw anymore. Depends where you ask; the freebsd-ipfw list archives may assist. Most problems turn out to be usage related, not to say there aren't still some bugs being addressed, lately several related to ipfw nat. > Triggering the issue requires a modified kernel (ipfw forward and ipfw > nat are not available by default), requires using ipfw nat (a relatively > new thing) instead of the old natd daemon, and requires changing the > value of a system setting. ipfw nat requires no kernel configuration, it'll load as a module. The only part of ipfw requiring kernel configuration nowadays is ipfw fwd, which can't be loaded as a module as it impacts many parts of the stack. Neither do you have to use ipfw nat; natd works as well as ever, but I'd be surprised if this isn't an issue more to do with your rule placement. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110623205741.K34951>