Hi there Oliver, OK, so you're definitely up to snuff on the issues implied by your config. I may be able to help you out on the "two interfaces on the same subnet" problem. At least for outbound packets. : If someone's got a solution to the problem 'two interfaces on the same : subnet', let me know. I've written a little bit about the ARP flux problem here: http://plorf.net/linux-ip/html/ch-ether.htm#ETHER-ARP-FLUX Basically there are four solutions: /proc/sys/net/ipv4/conf/*/rp_filter # kernel 2.4 only /proc/sys/net/ipv4/conf/*/hidden # patch to 2.4; in 2.2.14+ ip arp # patch to 2.4 and iproute2 ip route add <route> noarp # patch to 2.4 and iproute2 For description of the rp_filter solution see the IP sysctl tutorial: http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN616 For a description of the other three, see Julian's site: http://www.linuxvirtualserver.org/~julian/ Once you've solved the ARP flux problem (two NICs on one segment), you'll be able to do something like this: # ip rule add iif eth0 table main # ip rule add iif eth4 table t3 Then the main routing table would have a route out the ADSL line, and you could create table t3 with a route out your main connection. With all of that said, your firewall may send the inbound packets back to the clients via the "wrong" interface, but this should not matter, as the client machines will continue to cache the IP/MAC mapping for outbound packets--and these are the important ones for your configuration. I haven't ever tried this so I don't know what wrinkles you should expect, but....it should work (famous last words). : Source based routing would only be a second best solution. My task is to : let the user choose the outbound route. In this case I would have to : built a kind of user-interface to the firewall-script. I think that : would be a bad idea. On the other hand I want prevent people asking me : to switch theirs connection. What!? You are trying to lighten your workload? Sacrilege! :) -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
