Date: Fri, 29 Sep 2000 11:40:07 +0300 From: Ruslan Ermilov <ru@sunbay.com> To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Cc: Julian Elischer <julian@elischer.org> Subject: Re: ipfw(8) divert handling Message-ID: <20000929114007.B19780@sunbay.com> In-Reply-To: <00Sep29.162348est.115252@border.alcanet.com.au>; from peter.jeremy@alcatel.com.au on Fri, Sep 29, 2000 at 04:24:00PM %2B1100 References: <00Sep29.150454est.115252@border.alcanet.com.au> <Pine.BSF.4.10.10009282136500.21594-100000@InterJet.elischer.org> <00Sep29.162348est.115252@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 29, 2000 at 04:24:00PM +1100, Peter Jeremy wrote: > 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. > This is all nicely described in divert(4) manpage, have you looked there? Its section LOOP AVOIDANCE describes how outgoing packets re-enter firewall filter. > >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. > The natd(8) manpage has this info: : After translation by natd, packets re-enter the firewall at the rule : number following the rule number that caused the diversion (not the : next rule if there are several at the same number). > >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. > Yes, the ipfw(8) manpage is incorrect regarding the use of fw.one_pass. I have just committed a fix. > > 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. > But you can, by supplying the `allow' rule right after `divert' one :-) > > 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. > No need for that. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age 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?20000929114007.B19780>