From owner-freebsd-hackers Fri Jul 27 15:47:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by hub.freebsd.org (Postfix) with ESMTP id C61E437B405 for ; Fri, 27 Jul 2001 15:47:19 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp045-bsace7001.telebrasilia.net.br [200.181.80.45]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id PAA58124; Fri, 27 Jul 2001 15:46:40 -0700 (PDT) Message-ID: <3B61EFDD.ABD61EC3@newsguy.com> Date: Fri, 27 Jul 2001 19:49:01 -0300 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: mikescott@clara.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: natd passes inconsistent addresses to ipfw? References: <3B61424F.23282.7D8482@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 mikescott@clara.net wrote: > > With the following ipfw config fragment, Which happens not to include the rule that is denying your packets... > > # 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 > 00100 15 882 divert 8668 ip from any to any via tun0 > 00200 0 0 allow ip from any to any via lo0 > 00300 405 102963 allow ip from any to any via ed0 > 00400 0 0 unreach port log logamount 100 tcp from any to any > 113 in recv tun0 > 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 > 00800 1 210 allow udp from any 53 to any in recv tun0 > 00900 1 60 allow udp from any to any 53 out xmit tun0 > 01000 1 76 allow udp from any 123 to any 123 via tun0 > 65435 0 0 allow icmp from any to any > 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 > > (Note that dynamic rule shows the external IP address, where I > would have expected the internal address). The security log > contains: > > Jul 25 08:26:00 data /kernel: ipfw: Accounting cleared. > > Jul 25 08:26:39 data /kernel: ipfw: 700 Accept TCP > 213.104.70.121:1041 195.8.69.73:119 out via tun0 > ( ^^^^ Note the external address, setting up the dynamic rule) Sure. Packet enters through fxp0 (or whatever you have), packet gets diverted and natted, packet is then allowed by the keep-state rule. > Jul 25 08:26:39 data /kernel: ipfw: 600 Deny TCP 195.8.69.73:119 > 192.168.0.2:1041 in via tun0 > ( ^^^^ Note the Internal address, which doesn't match the > dynamic rule) Sure. Packet enters through tun0, packet gets diverted and natted, packet is then denied by the established rule (not having been recognized by the one with state). > > Jul 25 08:26:39 data /kernel: ipfw: 700 Accept TCP > 213.104.70.121:1041 195.8.69.73:119 out via tun0 > > Jul 25 08:26:39 data /kernel: ipfw: 600 Deny TCP 195.8.69.73:119 > 192.168.0.2:1041 in via tun0 > (and so on...) > > Not surprisingly, the connection then hangs. Running natd with the > -v option as well only shows the expected address translations; > nothing amiss. > > With less robust, non-dynamic rules, everything works fine. Can > anyone spot what's going on here please? It's doing precisely what you told it to. Perhaps if you would move the check-state before the nat? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message