From owner-freebsd-hackers Fri Jul 27 2:29:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by hub.freebsd.org (Postfix) with ESMTP id E0E0937B401 for ; Fri, 27 Jul 2001 02:29:35 -0700 (PDT) (envelope-from mikescott@clara.net) Received: from data.scotts ([213.104.68.196]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010727092933.VCUN298.mta03-svc.ntlworld.com@data.scotts> for ; Fri, 27 Jul 2001 10:29:33 +0100 Received: from picard (picard.scotts [192.168.0.2]) by data.scotts (8.11.3/8.11.3) with ESMTP id f6R9SWf14493 for ; Fri, 27 Jul 2001 10:29:29 +0100 (BST) From: mikescott@clara.net Organization: scott family To: freebsd-hackers@FreeBSD.ORG Date: Fri, 27 Jul 2001 10:28:31 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: natd passes inconsistent addresses to ipfw? Reply-To: mikescott@clara.net Message-ID: <3B61424F.23282.7D8482@localhost> 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 (I've tried this already on the "questions" list already, but without success. I hope it's not too trivial for this list -- either I'm missing something glaringly obvious (probable), or there's a bug. Either way, I'm stuck :-( ) It looks to me as though natd and ipfw interact inconsistently for inbound and outbound traffic, causing problems with dynamic rules in the firewall. I'm using FreeBSD 4.3-stable as a dial-up gateway machine for a small lan with some windows machines on it. The machine runs ppp (user mode), plus natd and ipfw. natd is running with switches -dynamic and -t 192.168.0.254. ppp is running with just -auto, and its config file doesn't enable aliasing. The gateway machine has local address 192.168.0.1, external address variable of course, but of the form 213.x.x.x. For testing purposes, from windows m/c 192.168.0.2, I ran "telnet 195.8.69.79 119", and waited for the news-server response With the following ipfw config fragment, # 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) 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) 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? -- 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