From owner-freebsd-hackers Sat Jul 28 4:19:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by hub.freebsd.org (Postfix) with ESMTP id 9EC2B37B403 for ; Sat, 28 Jul 2001 04:19:10 -0700 (PDT) (envelope-from mikescott@clara.net) Received: from data.scotts ([213.104.78.9]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010728111908.KMAP6330.mta06-svc.ntlworld.com@data.scotts>; Sat, 28 Jul 2001 12:19:08 +0100 Received: from picard (picard.scotts [192.168.0.2]) by data.scotts (8.11.3/8.11.3) with ESMTP id f6SBJ3f20095; Sat, 28 Jul 2001 12:19:05 +0100 (BST) From: mikescott@clara.net Organization: scott family To: "Daniel C. Sobral" Date: Sat, 28 Jul 2001 12:19:01 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: natd passes inconsistent addresses to ipfw? Reply-To: mikescott@clara.net Cc: freebsd-hackers@FreeBSD.ORG Message-ID: <3B62ADB5.17372.60982A6@localhost> In-reply-to: <3B61EFDD.ABD61EC3@newsguy.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 27 Jul 2001, at 19:49, Daniel C. Sobral wrote: > mikescott@clara.net wrote: > > > > With the following ipfw config fragment, > > Which happens not to include the rule that is denying your packets... Untrue -- it's the "deny log tcp from any to any established" in the fragment I gave (# 00600 in the ipfw listing below) > > > > # divert packets through the tunnel interface > > $fwcmd add divert natd all from any to any via tun0 > > ... > > # allow anything I start up (OK) > > # allow connections to continue once made (FAILS!) > > $fwcmd add check-state > > $fwcmd add deny log tcp from any to any established > > $fwcmd add allow log tcp from any to any out via tun0 setup keep- > > state > > > > I get the following typical failures happening > > > > data# ipfw zero > > Accounting cleared. > > > > (Run telnet session) > > > > data# ipfw show ... > > 00500 0 0 check-state > > 00600 8 344 deny log logamount 100 tcp from any to any > > established > > 00700 4 192 allow log logamount 100 tcp from any to any keep- > > state out xmit tun0 setup ... > > 65435 0 0 deny log logamount 100 ip from any to any > > 65535 0 0 deny ip from any to any > > ## Dynamic rules: > > 00700 3 144 (T 5, # 86) ty 0 tcp, 213.104.70.121 1041 <-> > > 195.8.69.73 119 > > ....... > > It's doing precisely what you told it to. Perhaps if you would move the > check-state before the nat? Well, I tried that - moved to to just after the 'flush'. That just hangs totally, presumably because although the packets do match at the check-state, the rules stop being checked as soon as there's a match, so the nat never happens. In fact, *anything* that matches before the nat diversion will stop the latter happening, surely, so the nat *must* be first. I'm worried about the logic of the problem -- it seems to me that there's no way that nat and the dynamic rules can work together correctly, given that both incoming and outgoing packets start at the top and work down the same list of rules. Tthe keep-state and check-state surely have to be on the same side of the nat, because they have to work together *either* on local *or* external addresses, not a mixture. But if they're after the nat (as for all written examples I've seen), then for incoming packets they operate on local addresses, and for outgoing on external addresses, which is not what's wanted. If they're before the nat, we never reach the nat. Am I totally at sea here with my understanding of what's going on? Does anyone on the list have a working example which they could offer, please, and set my mind at rest? -- various incoming sites blocked because of spam: see www.mikescott.clara.net for a list mikescott@clara.net Mike Scott aka mikeascott@ntlworld.com Harlow Essex England To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message