Isolating network interfaces on Linux

February 1, 2008

Consider a not entirely hypothetical situation: you have an office machine that serves as one end of a GRE tunnel, and, in addition to its official network interface, has a fluctuating number of secondary interfaces on various internal VLANs for testing, debugging, and so on. The simple approach for such a machine is to just turn on global IP forwarding and cross your fingers that no one will decide to make the machine their gateway (apart from the GRE link). But this is not ideal; if nothing else, it may alarm coworkers that you have an unofficial router on the network.

What we really want to do is to isolate the secondary interfaces, making it so that we won't forward their packets and we won't forward packets to them for other people. The first part is selective IP forwarding; just turn forwarding on only for eth0 and the GRE tunnel. The easiest way to do the second part is to use some policy based routing.

For my office machine, I decided to simplify things by declaring that the GRE tunnel was allowed to reach everything and thus only traffic from eth0 needed to be restricted. First we need to add a routing table for the non-local routes that eth0 is allowed to use, ie the target of the GRE link:

ip route add R dev GRE table 10

(Here R is the remote IP and GRE is the GRE tunnel device. You may want to add a 'src LOCAL-IP' as well.)

Next we need some rules to restrict eth0 traffic:

ip rule add iif eth0 priority 5000 table 10
ip rule add type blackhole iif eth0 priority 5001

Translated, this drops any traffic from eth0 that isn't going to the remote end of the GRE tunnel, exactly as if that interface didn't do IP forwarding. (Packets to the machine itself are dealt with by an earlier, default ip rule.)

This is not complete isolation, because we have not given the machine a dual identity for its own traffic. In my situation this is basically harmless, so I haven't gone to the extra effort.

Written on 01 February 2008.
« The sysadmin's life (again)
Why certified/authenticated email cannot solve spam »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 1 23:54:30 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.