From owner-freebsd-net Thu Sep 28 22:24:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id B0D8C37B43C for ; Thu, 28 Sep 2000 22:24:07 -0700 (PDT) Received: by border.alcanet.com.au id <115252>; Fri, 29 Sep 2000 16:23:48 +1000 Content-return: prohibited Date: Fri, 29 Sep 2000 16:24:00 +1100 From: Peter Jeremy Subject: Re: ipfw(8) divert handling In-reply-to: ; from julian@elischer.org on Thu, Sep 28, 2000 at 10:03:10PM -0700 To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Reply-To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Message-Id: <00Sep29.162348est.115252@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <00Sep29.150454est.115252@border.alcanet.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. >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