Date: Wed, 10 Apr 2002 22:08:16 -0700 From: "Crist J. Clark" <crist.clark@attbi.com> To: Joe & Fhe Barbish <barbish@a1poweruser.com> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/36895: natd does not function correctly when ipfw rules use check-state/keep-state Message-ID: <20020410220816.A37066@blossom.cjclark.org> In-Reply-To: <LPBBIGIAAKKEOEJOLEGOOELFCNAA.barbish@a1poweruser.com>; from barbish@a1poweruser.com on Wed, Apr 10, 2002 at 01:47:28PM -0400 References: <20020409231719.C34659@blossom.cjclark.org> <LPBBIGIAAKKEOEJOLEGOOELFCNAA.barbish@a1poweruser.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 10, 2002 at 01:47:28PM -0400, Joe & Fhe Barbish wrote:
> Chris you replied with the following
>
> OK, serious deja vu. Didn't we go through this once before? Every
> single one of the 'keep-state' rules is for packets crossing the tun0
> interface and only the tun0 interface. This won't work. As we see in
> the rules that get created.
>
> All of the rules outgoing packets that trigger the keep-state rules
> have a source of the aliased address. When they come back in, they are
> translated by the 'divert' rule, 00200, before they hit the
> 'check-state' rule. They have a 10.0.10.0/29 address after 00200, so
> they match no dynamic rule, fall through the list, and get dropped.
>
> And I say SO WHAT'S YOUR POINT?
>
> You have not done anything but point out that divert natd does not work
> with keep-state rules just like I said.
It doesn't work in the way you have set it up for the way you want to
use them.
> The ipfw divert natd rule is in the rc.firewall sample implies it can
> be used on any interface.
It can be used on any interface.
> If I code this same rule set using stateless rules and simple stateful
> setup/established rules the divert nated works just fine using tun0,
> just like in the rc.firewall sample.
Right, everything in the sample works fine.
> [[[This is not a question of which interface is being used, but one of which
> ip address (private or public) is being posted in the dynamic rules table
> and the ipfw divert natd function lacking the knowledge that dynamic rules
> are enabled, and modifying it's behavior to accommodate this fact.]]]
>
> My PR is saying the ipfw divert natd function does not work using advanced
> stateful rules which build entries in the dynamic rules table, and the test
> documentation I sent you prove it.
It doesn't work the way you want them to. They work just as they are
advertised. There are no bugs. This is an enhancement or change
request.
> Fix the ipfw divert natd function so it is aware when advanced stateful
> rules are in use,
>
> or
>
> change the ipfw divert natd documentation to say it does not work in a
> ipfw rule set that contains any rules that use the keep/state option.
If someone wants to do this, they can try, but it is going to be a
mess. natd(8) lives separate from the ipfw(8) rules for a
reason. Trying to get natd(8) to know about firewall rules breaks the
whole model. If someone really wants to do this, they might be better
off starting from scratch and doing it all in the kernel.
> This is an oversight that should have been address when the keep-state
> option was first introduced.
The two were developed independently. natd(8) has existed much longer
than 'keep-state' rules.
> I do not think you should have closed this PR. I want an second opinion.
> Please reopen the pr, post our email correspondences to it, and email the
> other IPFW team members to review the pr.
Huh? I just closed it now after I saw this mail. If I recall the
thread on the mail lists, at least lugui and ru told you the same
thing.
> There is a problem here even if you can not see it.
> Other people's eyes and minds may have a different perspective of the test
> results.
>
> It's time to move this up the hill to get additional view points besides
> just yours.
If you can find someone who wants to do the work, great. I don't think
any of the current ipfw(8) and natd(8) hackers see much of a
problem. If you want to make this work, you can, just not with the
rules you are using.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020410220816.A37066>