On Fri, 27 Apr 2001, Phil Karn wrote: > Until recently I had been tracking the 2.2.x kernel series. Since > I installed 2.4.3 (and just now 2.4.4) I have been unable to make > IP masquerading/NAT work. > > If I configure policy routing on and netfilter off, I can establish my > existing policy tables that deal with my rather complex ipip tunnel & > NAT configuration. Everything works as it did under 2.2.19 *except* > that policy entries calling for masquerading no longer work. Reading below - Quick answer: You can configure netfilter on but _not_ conntrack or any of the NAT funtions iff you want to use map-to (FastNAT). FastNAT will coexist quite nicely with NetFilter including the mangle table (for nfmark'ing) so long as conntrack is never loaded. > Here is the output of "ip rule list": > > 0: from all lookup local > 10: from 199.106.106.0/28 lookup ka9q > 11: from 129.46.253.96/28 lookup qualcomm > 20: from 192.168.0.0/24 iif eth0 lookup main map-to 24.130.169.53 At this point you can make a decision. Instead of using FastNAT you can use SNAT in many-to-one mode to coalesce this mapping. Essentially the SNAT happens in the Post-Routing stage which is after the RPDB (rules etc) has been traversed. If you decide to use SNAT then you can remove Rule 20 (as default rule 32766 will take care of the situation) and use something such as: iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0/24 \ -j SNAT --to 24.130.169.53 > 32766: from all lookup main > 32767: from all lookup default > > And here are my routing tables and interfaces: > > bash-2.03$ ip route list > 199.106.116.12/30 dev eth0 proto kernel scope link src 199.106.116.14 > 129.46.253.96/29 dev eth0 proto kernel scope link src 129.46.253.98 > 199.106.106.0/28 dev eth0 proto kernel scope link src 199.106.106.3 > 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 > 129.46.0.0/16 via 129.46.253.97 dev eth0 > 224.0.0.0/8 dev eth0 scope link src 199.106.106.3 > default via 24.130.168.1 dev eth1 src 24.130.169.53 onlink Default Rule 32766 will ensure that all packets not accounted for will take this default route. This default route will then end up sending those packets into the SNAT mapping above. > bash-2.03$ ip route list table ka9q > 199.106.106.0/28 dev eth0 scope link > 10.0.0.0/24 dev eth0 scope link > default via 192.35.156.12 dev tunl0 onlink > bash-2.03$ ip route list table qualcomm > default via 129.46.253.97 dev eth0 > bash-2.03$ ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 00:03:47:39:74:AE > inet addr:199.106.106.3 Bcast:199.106.106.15 Mask:255.255.255.240 > UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:352 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2846 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > Interrupt:11 Base address:0xe000 > > bash-2.03$ ifconfig eth1 > eth1 Link encap:Ethernet HWaddr 00:A0:24:4A:BF:FD > inet addr:24.130.169.53 Bcast:24.255.255.255 Mask:255.255.255.255 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:4964 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5085 errors:0 dropped:0 overruns:0 carrier:0 > collisions:16 txqueuelen:100 > Interrupt:7 Base address:0xdf80 > bash-2.03$ ifconfig tunl0 > tunl0 Link encap:IPIP Tunnel HWaddr > inet addr:24.130.169.53 Mask:255.255.255.255 > UP RUNNING NOARP MTU:1480 Metric:1 > RX packets:222 errors:0 dropped:0 overruns:0 frame:0 > TX packets:214 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > > The "map-to" policy entry worked fine under 2.2.19 but is apparently > ignored under 2.4.3 and 2.4.4; packets from 192.168.0.0/24 go out > un-NATed. The same happens if I make the map-to address null, in which > case the "map-to" keyword is replaced with "masquerade". True iff conntrack is loaded. I am assuming of course that you are using a rule similar to: ip rule add from 192.168.0/24 nat 24.130.169.53 prio 20 > Is 2.4.x supposed to be backward compatible with the 2.2.x style > policy routing and NAT mechanism? Or must I use the ipchains module > under netfilter to reimplement this? Yes - No - Never got it to work completely. Yes to compatibility bearing in mind the interactions mentioned above. No you do not need to use the ipchains module iff the SNAT would work (and your situation does not seem complex enough to warrent the fiddling). And I have never gotten the "src" mapping to work with the ipchains module. This brings up the point that what is actually performing the Masquerade in your situation above is the "src" parameter to your route. In IPCHAINS iff you had a Masquerade parameter on your Forward chain then ipchains would default to using the value of the "src" parameter for all Masq'ed traffic. IE: If you had a dev dummy0 with 10.1.1.1/32 addressing and you then issued on your system above a route such as: ip ro ad default via 24.130.169.1 src 10.1.1.1 table main Then all outgoing masq'ed packets would have thier src address set to 10.1.1.1 - Cool trick that I used extensively under IPCHAINS. > I tried a kernel with netfilter turned on, but I was then no longer > able to load the ipip.o module that I use for tunneling. I get two > unresolved symbols from insmod: nf_hooks and nf_hooks_slow. Yet both > symbols *are* mentioned in /System.map. Weird. This persisted even > after a 'make clean' and remake. Best to compile the tunnel into the kernel (IE: CONFIG_NET_IPIP=y and CONFIG_NET_GRE=y) as if they are not used they do not hurt anything. > Appended is my /usr/src/linux/.config file with netfilter turned > off. Following that is the output of /usr/src/linux/scripts/ver_linux. > > Thanks, > > Phil Karn [snip] Let me know if you need more - BTW: http://www.policyrouting.org -------------------------------------------------- Matthew G. Marsh, President Paktronix Systems LLC 1506 North 59th Street Omaha NE 68104 Phone: (402) 932-7250 x101 Email: mgm@paktronix.com WWW: http://www.paktronix.com -------------------------------------------------- - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
