From owner-freebsd-net@FreeBSD.ORG Sat Jun 14 23:36:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89A6637B401 for ; Sat, 14 Jun 2003 23:36:54 -0700 (PDT) Received: from metalhead.pwrsrc.net (client108.fre.communitycolo.net [64.62.161.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 069DC43FBD for ; Sat, 14 Jun 2003 23:36:54 -0700 (PDT) (envelope-from mrp@pwrsrc.net) Received: from adsl-64-175-66-198.dsl.pltn13.pacbell.net ([64.175.66.198] helo=pwrsrc.net) by metalhead.pwrsrc.net with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 19RR85-0007WJ-00 for ; Sat, 14 Jun 2003 23:36:41 -0700 Message-ID: <3EEC14D2.1020705@pwrsrc.net> Date: Sat, 14 Jun 2003 23:40:18 -0700 From: I-Gene Leong User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Subject: ipfw + ppp -nat: packets not being filtered correctly? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2003 06:36:54 -0000 I'm not sure if this should go to -net or -security, so my apologies if this goes to the wrong place. Since I'm not subscribed, please cc any responses to me. I'm using ipfw and ppp -nat on a FreeBSD 4.8-STABLE system to provide Internet connectivity to an internal network. My firewall rules are set up this way: 00100 divert 8668 ip from any to any 00200 check-state 00300 deny ip from 10.0.0.0/8 to any in recv tun0 00400 deny ip from 172.16.0.0/12 to any in recv tun0 00500 deny ip from 192.168.0.0/16 to any in recv tun0 00600 deny ip from 0.0.0.0/8 to any in recv tun0 00700 deny ip from 169.254.0.0/16 to any in recv tun0 00800 deny ip from 192.0.0.0/16 to any in recv tun0 00900 deny ip from 224.0.0.0/4 to any in recv tun0 01000 deny ip from 240.0.0.0/4 to any in recv tun0 01100 skipto 4000 ip from any to any recv tun0 01200 skipto 4000 ip from any to any out xmit tun0 01300 allow tcp from any to any setup keep-state 01400 deny tcp from any to any 01500 allow ip from any to any keep-state 04000 check-state log 04100 allow tcp from me to any out setup keep-state 04200 deny tcp from me to any out 04300 allow ip from me to any out keep-state 04400 allow tcp from 10.0.0.0/24 to any out via tun0 setup keep-state 04500 deny tcp from 10.0.0.0/24 to any out via tun0 04600 allow ip from 10.0.0.0/24 to any out via tun0 keep-state 04700 allow tcp from any to me dst-port 22,80 in recv tun0 setup keep-state 04800 reset tcp from any to me dst-port 113 in 04900 allow icmp from any to any icmptypes 0,3,8,11,12,13,14 05000 deny ip from any to any 65535 deny ip from any to any Now, it seems to me rules 1100 and 1200 should pass all packets that have anything to do with tun0 up to rule 4000 (which is redundant, but just a remnant from earlier experimentation). I want rules 1300 to 1500 to apply to all traffic that is not destined for tun0. This is the case for all traffic generated on the FreeBSD system itself; it all gets passed onto rules 4000-4300 instead. However, the dynamic rules list shows: ## Dynamic rules (123): 01300 41 19410 (298s) STATE tcp 10.1.0.2 3360 <-> 216.136.204.117 80 01300 331 35856 (291s) STATE tcp 10.1.0.2 3261 <-> 205.188.11.212 5190 01300 239 146496 (279s) STATE tcp 10.1.0.5 4266 <-> 64.62.161.18 993 01300 239 16580 (216s) STATE tcp 10.1.0.2 3297 <-> 207.46.107.40 1863 01300 195 18068 (282s) STATE tcp 10.1.0.2 3259 <-> 205.188.10.96 5190 01300 350 58220 (300s) STATE tcp 10.1.0.2 3250 <-> 10.1.0.1 22 01300 79 5352 (297s) STATE tcp 10.1.0.2 3262 <-> 205.188.1.79 5190 01300 73 5530 (272s) STATE tcp 10.1.0.2 3254 <-> 216.136.226.208 5050 01300 81 8654 (299s) STATE tcp 10.1.0.2 3263 <-> 64.12.26.27 5190 01300 231 81254 (297s) STATE tcp 10.1.0.2 3273 <-> 216.239.33.99 80 01300 205 63476 (297s) STATE tcp 10.1.0.2 3274 <-> 216.239.33.99 80 All of these rules come from packets originating inside the internal network and were generated by rule 1300, despite the destinations clearly being elsewhere on the Internet. (To me, all these should have been generated by rule 4400.) Additionally, if I enable logging on rule 1500 and then ping an outside host from an inside host, I see the following: Jun 14 22:59:25 icecube /kernel: ipfw: 1500 Accept ICMP:8.0 10.1.0.2 64.62.161.18 in via rl0 Jun 14 22:59:25 icecube /kernel: ipfw: 1500 Accept ICMP:8.0 10.1.0.2 64.62.161.18 out via tun0 Jun 14 22:59:25 icecube /kernel: ipfw: 1500 Accept ICMP:0.0 64.62.161.18 10.1.0.2 in via tun0 Jun 14 22:59:25 icecube /kernel: ipfw: 1500 Accept ICMP:0.0 64.62.161.18 10.1.0.2 out via rl0 I'm wondering where this apparent "doubling" of packets comes from, and more importantly, how to get these packets away from rule 1500 and handled by rule 4600 instead. Thoughts or ideas? Thanks in advance. - I-Gene