Date: Tue, 4 Jul 2000 14:26:39 +0200 From: Marc Silver <marcs@draenor.org> To: Udo Erdelhoff <ue@nathan.ruhr.de> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: ipfw & natd strangeness Message-ID: <20000704142639.L82739@draenor.org> In-Reply-To: <20000704140841.A240@nathan.ruhr.de>; from ue@nathan.ruhr.de on Tue, Jul 04, 2000 at 02:08:42PM %2B0200 References: <20000704140841.A240@nathan.ruhr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey there, I'm not entirely sure that count will work the way you want it to if you're going to be using packet forwarding. :) I haven't actually looked at this myself, but I'll take a look at it sometime on the weekend and if I find out otherwise, I will email and let you know. The problem I think is that with my firewall rules _ALL_ traffic is diverted through tun0, so I'm doubtful that counts will work on interfaces like eth1 etc. Perhaps someone else would have more of an idea....?? :) By the way, to my knowledge, the divert rule should be first and foremost. Cheers, Marc On Tue, Jul 04, 2000 at 02:08:42PM +0200, Udo Erdelhoff wrote: > 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?20000704142639.L82739>