Paul, : I have a system which has two ethernet interfaces to cable modems. The : cable modems have NAT active on them. I also have one ethernet : interface connected to my home LAN. I have followed the documentation : and have setup split access such that I can route answers to packets : coming in over a particular provider back out again over that same : provider. : : I now want to be able to start an application and select the interface : over which it will route frames. For example: If I use ping with the : -i option the routing works. However if I don't use the -i option then : the network is deemed unreachable. I would expect this as there is no : route to the destination address in the tables and I assume that the : source address that is being used has been taken from my hostname which : does not match either of my interfaces. Source address selection is based on route selection [1] [2]. What does your default route look like? I'm puzzled that you say you are able to specify an interface (with ping -i) and reach the destination, however without specifying an interface, the kernel should look up a route for you, and then (if there still isn't a source address on the packet) supply a source address for the outbound packet. What do your routing tables look like? "ip route show" for all tables What does your RPDB look like? "ip rule show" : How do I solve this issue my current thoughts are : : Add iptables entry when the process is created to set the MARK based on : the owner e.g. SID or PID. Add ip rule to route from MARK to the tables : created as as result of split access. : : Is this the most efficient method to achieve this solution or is there : some other trick that I could use ? Because I don't understand what the problem is yet, I'm not going to comment on whether this trick or another trick would be fruitful. Perhaps you can give us some hard details and show us how it isn't working as you had expected/hoped? Best, -Martin [1] http://linux-ip.net/html/routing-saddr-selection.html [2] http://linux-ip.net/gl/ip-cref/node155.html [3] -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx