Date: Fri, 25 Jul 2003 10:57:43 -0400 From: Andriy Gapon <agapon@cv-nj.com> To: ipfw@FreeBSD.org Subject: Re: Dynamic rules not being matched after divert... Message-ID: <3F214567.9060308@cv-nj.com>
next in thread | raw e-mail | index | archive | help
Sean, it's understandable why you are tempted to call the interaction between ipfw stateful rules and natd a bug, but you are wrong. Yes, in both cases the packets are matched against the dynamic rules after address transaltion, but that's exactly the problem - the outgoing packets already have an external src address, but the incoming packest already have an internal dst address - obviously they won't match. Advice from Michael Sierchio is pretty reasonable, and I am not sure why you would want to see internal state table of natd - if you want to account traffic or take a look at the established connections, then there are the specialized tools for that e.g. trafshow, trafd. However, if you have reasons to not fully trust natd, and you don't mind performance overhead of having both dynamic ipfw rules and natd, then there is a solution as well - it is to use skipto dynamic rules. In the case you haven't found it while searching for the previous discussions on this topic, both "trusted natd" and "non trusted natd" ideas are explained a little bit more here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=11483+0+archive/2002/freebsd-ipfw/20021027.freebsd-ipfw I can provide the examples of the working sets of the rules upon request. I do not promise however to generalize them from my specific setup or to find a time to give an advice on your specific setup. P.S. about the ipfw page - it is correct (but a bit confusing for a novice), the search does terminate. It's just that natd (and probably all other reasonable daemons that use divert) *reinserts* a packet after the same rule. But it isn't required to reinsert at that place, nor it is required to reinsert a packet at all. divert(4). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F214567.9060308>