From owner-freebsd-net  Thu Sep 28 23: 4:45 2000
Delivered-To: freebsd-net@freebsd.org
Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231])
	by hub.freebsd.org (Postfix) with ESMTP id 550CC37B423
	for <freebsd-net@FreeBSD.ORG>; Thu, 28 Sep 2000 23:04:25 -0700 (PDT)
Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148])
	by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id OAA29871;
	Fri, 29 Sep 2000 14:04:15 +0800
Received: from elischer.org (reggae-39-24.nv.iinet.net.au [203.59.173.24])
	by popserver-02.iinet.net.au (8.9.3/8.9.3) with ESMTP id OAA03064;
	Fri, 29 Sep 2000 14:04:06 +0800
Message-ID: <39D430C0.31F34AA@elischer.org>
Date: Thu, 28 Sep 2000 23:03:44 -0700
From: Julian Elischer <julian@elischer.org>
X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au
Subject: Re: ipfw(8) divert handling
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Peter Jeremy wrote:
> 
> On 2000-Sep-28 22:03:10 -0700, Julian Elischer <julian@elischer.org> wrote:
> >Your confusion results from considering the actions 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.

then I guess we should change the documentation.
How would YOU express that idea? (and where)

> 
> >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.

ok

> 
> >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.

That's not the kernel's problem...
I also think that the section in the man page re: one_pass and divert
should
be removed.

> 
> > As I mentionned before, a packet injected into the
> >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.

sure

> 
> Peter
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Perth
            v


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message