Date: Tue, 4 Jul 2000 14:08:42 +0200 From: Udo Erdelhoff <ue@nathan.ruhr.de> To: freebsd-questions@FreeBSD.ORG Subject: ipfw & natd strangeness Message-ID: <20000704140841.A240@nathan.ruhr.de>
next in thread | raw e-mail | index | archive | help
Hi, I've just read Marc Silver's tutorial on "Dialup firewalling wiht FreeBSD". The tutorial shows how to use natd & ipfw instead of ppp's internal packet aliasing and filtering. I've decided to try his method because I wanted some of ipfw additional features (reset and log). Additionally, I wanted to add some additional rules to stop packets with source adresses from the rfc1918 networks. The packet aliasing stuff works as expected but I've noticed a couple strange things when using "count" filters. The basic setup is: Client 192.168.1.3 <----> ed1: 192.168.1.1 Router (tun0: dynip) <---> The outgoing connection uses PPPoE. I hope that doesn't complicate things. kernel configuration: options IPFIREWALL, IPFIREWALL_VERBOSE, NETGRAPH, NG_PPPOE, NG_SOCKET. net.inet.ip.forwarding is set to 1, everything else has its default value. The ruleset for the firewall consists of a divert rule surronded by a lot of count rules. Each block (before and after the divert rule) contains one count rule for each legal combination of 192.168.1.3/any, in/out, recv/xmit, tun/ed0. In other words, 12 rules in each block: 100 count ip from 192.168.1.3 to any in recv tun0 101 count ip from 192.168.1.3 to any in recv ed1 110 count ip from 192.168.1.3 to any out recv tun0 111 count ip from 192.168.1.3 to any out recv ed1 120 count ip from 192.168.1.3 to any out xmit tun0 121 count ip from 192.168.1.3 to any out xmit ed1 130 count ip from any to 192.168.1.3 in recv tun0 131 count ip from any to 192.168.1.3 in recv ed1 140 count ip from any to 192.168.1.3 out recv tun0 141 count ip from any to 192.168.1.3 out recv ed1 150 count ip from any to 192.168.1.3 out xmit tun0 151 count ip from any to 192.168.1.3 out xmit ed1 200 divert natd ip from any to any via tun0 300 count ip from 192.168.1.3 to any in recv tun0 301 count ip from 192.168.1.3 to any in recv ed1 310 count ip from 192.168.1.3 to any out recv tun0 311 count ip from 192.168.1.3 to any out recv ed1 320 count ip from 192.168.1.3 to any out xmit tun0 321 count ip from 192.168.1.3 to any out xmit ed1 330 count ip from any to 192.168.1.3 in recv tun0 331 count ip from any to 192.168.1.3 in recv ed1 340 count ip from any to 192.168.1.3 out recv tun0 341 count ip from any to 192.168.1.3 out recv ed1 350 count ip from any to 192.168.1.3 out xmit tun0 351 count ip from any to 192.168.1.3 out xmit ed1 03000 allow ip from any to any via lo0 03010 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any (the "real" filtering is still done by ppp) First strange thing: ``net.inet.ip.fw.one_pass: 1 When set, permits only one pass through the firewall. Otherwise, after a pipe or divert action, the packet is reinjected in the firewall starting from the next rule.'' ipfw(4), section SYSCTL VARIABLES The test: ipfw zero, download a 9 MByte file from a server somewhere in the internet onto the client, ipfw show. zero the counters again, set net.inet.ip.fw.one_pass from 1 to 0, repeat download, ipfw show. The first strange thing: The results of the two test runs are identical. In other words, the sysctl knob doesn't influence the system behaviour when packets are diverted to natd. The description of the divert rule doesn't mention this variable, either (the description of the pipe rule does mention it). The second strange thing is the output of ipfw show. My assumption was that a packet matching a divert rule can be changed by it and it will always be reinjected into the firewall starting from the next rule. The effect of the rules after the divert rule are based on the new source/destination adress of the packet. The theory sounds great, the reality is a little bit different: [Results have been grouped by interface] 00101 3480 142158 count ip from 192.168.1.3 to any in recv ed1 00111 3437 139898 count ip from 192.168.1.3 to any out recv ed1 00121 0 0 count ip from 192.168.1.3 to any out xmit ed1 00131 0 0 count ip from any to 192.168.1.3 in recv ed1 00141 0 0 count ip from any to 192.168.1.3 out recv ed1 00151 6699 9767315 count ip from any to 192.168.1.3 out xmit ed1 [divert rule] 00301 3480 142158 count ip from 192.168.1.3 to any in recv ed1 00311 0 0 count ip from 192.168.1.3 to any out recv ed1 00321 0 0 count ip from 192.168.1.3 to any out xmit ed1 00331 0 0 count ip from any to 192.168.1.3 in recv ed1 00341 0 0 count ip from any to 192.168.1.3 out recv ed1 00351 6699 9767315 count ip from any to 192.168.1.3 out xmit ed1 101: The various http requests and a little bit of traffic for my ssh connection from the client to the server. Makes sense. 111: Most of these packets have a destination != the local machine. Ok. 121,131,141: Obviously correct 151: This is the first result I don't understand. That's obviously the traffic resulting from the requests. The strange thing is that it shows up before the divert rule takes any effect. At this point, the packets should have the web server address as source and my tun0-adress as destination. 301: Packets coming in through ed1 still come in through that device. 311: That's the expected result of diverting: The source address was changed. 321,331,341: Obvious. 351: The second expected result of diverting: That's the traffic originating from the server after being translated, going out through the ethernet. Now the result for the tun0 interface: 00100 0 0 count ip from 192.168.1.3 to any in recv tun0 00110 0 0 count ip from 192.168.1.3 to any out recv tun0 00120 3437 139898 count ip from 192.168.1.3 to any out xmit tun0 00130 0 0 count ip from any to 192.168.1.3 in recv tun0 00140 6671 9765627 count ip from any to 192.168.1.3 out recv tun0 00150 0 0 count ip from any to 192.168.1.3 out xmit tun0 00200 10108 9905525 divert 8668 ip from any to any via tun0 00300 0 0 count ip from 192.168.1.3 to any in recv tun0 00310 0 0 count ip from 192.168.1.3 to any out recv tun0 00320 0 0 count ip from 192.168.1.3 to any out xmit tun0 00330 6671 9765627 count ip from any to 192.168.1.3 in recv tun0 00340 6671 9765627 count ip from any to 192.168.1.3 out recv tun0 00350 0 0 count ip from any to 192.168.1.3 out xmit tun0 100,110: Obvious 120: My request will by transmitted through tun0 (default route) 140: Like #151 in the first block. Traffic from the outside with .1.3. as destination address shouldn't show up before passing through natd. 150: Obvious 200: Lots of traffic through natd. 300,310,320: Obvious 330: The destination adress is .1.3. after natd, the packets came in, through tun0. Looks strange, but correct. 340: See 330 - those packets have to leave the system somehow. 350: Obvious What's the cause for the strange results from rules 151 and 140? Are they a side effect of enabling IP forwarding with net.inet.ip.forward=1? The machine in questions runs a -current from 06/22. /s/Udo -- Schnell und schluepfrig wie geoeltes Ferkel auf Crack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000704140841.A240>