Date: Thu, 11 Apr 2002 08:19:33 -0400 From: "Joe & Fhe Barbish" <barbish@a1poweruser.com> To: <cjclark@alum.mit.edu> Cc: <freebsd-bugs@FreeBSD.ORG> Subject: RE: kern/36895: natd does not function correctly when ipfw rules use check-state/keep-state Message-ID: <LPBBIGIAAKKEOEJOLEGOKEMJCNAA.barbish@a1poweruser.com> In-Reply-To: <20020410220816.A37066@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>Right, everything in the sample works fine.
Except the keep-state rules.
>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.
Call it what you want, ipfw natd does not work with keep-state rules.
I have proved that fact with the test docs I sent you.
>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.
I am just using the PR as the vehicle to inform the ipfw maint team
about a problem, it's up to them to take corrective action or not.
>If I recall the thread on the mail lists, at least lugui and ru told
>you the same thing.
You recall wrong. You are the only person to post to the questions
list on this PR.
>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.
That is not for you to decide.
Leave the pr open and let the team decide for them selves, just like any
other pr.
>If you want to make this work, you can, just not with the rules you are
using.
If you are saying there is some other way to use the keep-state option that
will work with natd, then why have you not said so before this.
If your saying to return to using stateless rules and setup/established then
that's un-acceptable as that results in a firewall that's way to easy
to penetrate. That's the reason people used IPFILTER before keep-state
option came out.
Ipfw keep-state works correctly with user ppp -Nat so I will stay with it.
If nothing else you need to change the natd man page info to state it does
not work with keep-state rules.
If you want me to create an pr to the doc group, I can do that.
-----Original Message-----
From: Crist J. Clark [mailto:crist.clark@attbi.com]
Sent: Thursday, April 11, 2002 1:08 AM
To: Joe & Fhe Barbish
Cc: freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/36895: natd does not function correctly when ipfw rules
use check-state/keep-state
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?LPBBIGIAAKKEOEJOLEGOKEMJCNAA.barbish>