From owner-freebsd-bugs Thu Apr 11 5:19:45 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from mail.mango-bay.com (mail.mango-bay.com [208.206.15.12]) by hub.freebsd.org (Postfix) with ESMTP id 7BED237B41C for ; Thu, 11 Apr 2002 05:19:38 -0700 (PDT) Received: from barbish ([63.70.155.57]) by mail.mango-bay.com (Post.Office MTA v3.5.3 release 223 ID# 0-52377U2500L250S0V35) with SMTP id com; Thu, 11 Apr 2002 08:19:36 -0400 From: "Joe & Fhe Barbish" To: Cc: Subject: RE: kern/36895: natd does not function correctly when ipfw rules use check-state/keep-state Date: Thu, 11 Apr 2002 08:19:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020410220816.A37066@blossom.cjclark.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >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