From owner-freebsd-net Fri Sep 29 1:40:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 78F0537B423 for ; Fri, 29 Sep 2000 01:40:17 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id LAA24381; Fri, 29 Sep 2000 11:40:07 +0300 (EEST) Date: Fri, 29 Sep 2000 11:40:07 +0300 From: Ruslan Ermilov To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Cc: Julian Elischer Subject: Re: ipfw(8) divert handling Message-ID: <20000929114007.B19780@sunbay.com> Mail-Followup-To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au, Julian Elischer References: <00Sep29.150454est.115252@border.alcanet.com.au> <00Sep29.162348est.115252@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 +1100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 04:24:00PM +1100, Peter Jeremy wrote: > On 2000-Sep-28 22:03:10 -0700, Julian Elischer 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