On Mon, 2002-09-23 at 17:33, Lukas Eppler wrote: > Has anyone of you set up a NAT server connecting to more than one ISP?
Yes, in a few different places. > We are switching isp's and I wanted to avoid downtime by using both > networks simultaneously for some time. It's a good option. > So what do you suggest, should I > 1) Write everything by hand, not using ipmasq, Not sure on what ipmasq does (never used it), so long as it handles masquerading outbound traffic you'll probably be ok. > 2) Extend ipmasq's rules somehow to fire the routing tables up correctly > 3) Just run a script after ipmasq to introduce Yes. > root# ip route show > xx.yy.zz.16/29 dev eth2 proto kernel scope link src xx.yy.zz.17 > aa.bb.cc.160/28 dev eth0 proto kernel scope link src aa.bb.cc.162 > 10.0.0.0/8 dev eth1 proto kernel scope link src 10.0.0.1 > default via aa.bb.cc.161 dev eth0 Roughly speaking this is how I have done it, hopefully you find the example useful: #/bin/sh #--- Start of example ---# # Routing table for each net, containing appropriate default route ip route add default via xx.yy.zz.17 table 10 ip route add default via aa.bb.cc.161 table 20 # start priority of rules PRI=1000 # Anything going inside must be routed normally INT_NETS='192.168.0.0/24 192.168.16.0/22' for net in $INT_NETS; do ip rule add to $net lookup main pri $PRI PRI=`expr $PRI + 10` done # Force specific traffic to go the way you want it # DMZ server 192.168.0.10 goes out on old connection ip rule add from 192.168.0.10 lookup 10 map-to xx.yy.zz.18 pri $PRI # DMZ server 192.168.0.11 goes out new connection PRI=`expr $PRI + 10` ip rule add from 192.168.0.11 lookup 20 map-to aa.bb.cc.164 pri $PRI # Force LAN to go out old network for now PRI=`expr $PRI + 10` ip rule add from 192.168.16.0/22 lookup 10 map-to xx.yy.zz.19 pri $PRI # Make sure any leftovers go out the right way PRI=`expr $PRI + 10` ip rule add from xx.yy.zz.16/29 lookup 10 pri $PRI ip rule add from aa.bb.cc.160/28 lookup 20 pri $PRI # Flush routing cache to immediately activate changes ip route flush cache #--- End of example ---# One issue we have run into is that Linux masquerading seems to remember how it NATed packets and ignore changes requested in NATing via ip rules. For example here on my firewall is a NATed connection going to google: [root@somewhere /root]# ipchains -M -L -n|grep 216.239.51.101 TCP 14:58.15 10.142.254.1 216.239.51.101 35293 (62553) -> 80 If I decide to route 10.142.254.1 through a different connection with a rule like 'ip rule add from 10.142.254.1 lookup 20 map-to aa.bb.cc.165 pri $PRI' it wouldn't work until all Masquerading entries had cleared. The packets would actually be sent out the new route but they would have the old source adddress still (that which it was masqueraded to at the time of the still living masquerade entries). This problem makes it very difficult to change routing on the fly, I haven't found any way to flush masqueraded entries (please if there is one let me know). Hopefully the 2.4 linux kernel, and iptables, handle this issue better. The solution we use is to have servers multi-homed internally as well as externally. If you don't have incoming traffic (port forwarded) then this probably won't be an issue. This might be too much information so I'll stop now, hopefully I made at least a little sense. If you have more questions just followup to the list and I will try to respond. > default via xx.yy.zz.22 dev eth2 src xx.yy.zz.17 I've never had any luck with the src argument either. Fraser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
