Date: Thu, 28 Sep 2000 23:03:44 -0700 From: Julian Elischer <julian@elischer.org> To: freebsd-net@FreeBSD.ORG, peter.jeremy@alcatel.com.au Subject: Re: ipfw(8) divert handling Message-ID: <39D430C0.31F34AA@elischer.org> 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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39D430C0.31F34AA>