Date: Fri, 29 Sep 2000 16:24:00 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw(8) divert handling Message-ID: <00Sep29.162348est.115252@border.alcanet.com.au> In-Reply-To: <Pine.BSF.4.10.10009282136500.21594-100000@InterJet.elischer.org>; from julian@elischer.org on Thu, Sep 28, 2000 at 10:03:10PM -0700 References: <00Sep29.150454est.115252@border.alcanet.com.au> <Pine.BSF.4.10.10009282136500.21594-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-Sep-28 22:03:10 -0700, Julian Elischer <julian@elischer.org> wrote: >Your confusion results from considering the adtions after the divert and >before the divert as being the same pass. Your explanation makes sense, but isn't obvious from the perspective of someone writing a NAT firewall using ipfw. >It so happens, (what a coincidence!) that the state coming out and the >state sent in are identical in format and semantics. The result of this is >that if you re-submit a received packet, along with the state information >that was received with it, the filtering is started at the next higher >rule number than that at which the original divert occured. This is mentioned in the divert(4) man page, but I think it should be in the ipfw(8) and/or natd(8) man pages. >So the man page is correct . The search DID terminate. Not totally, elsewhere it says that the behaviour depends on one_pass (the sysctl description of one_pass in the code says the same thing). Also, it fails to mention that the search will restart if the diverted packet re-enters the kernel. > If the daemon wants to inject a packet that >does not pass through any more ipfw rules it can specify the rule number >of an 'accept rule' directly. natd(8) can't do this. > As I mentionned before, a packet injected into teh >system is a NEW packet. it cannot and should not be considerred to be the >same packet as one that was previously diverted.. Thanks for that. Unless someone comes up with a more convincing reason to support my original POV, I'll write a PR to clarify the documentation and make it match the code. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Sep29.162348est.115252>