Computer Laboratory

VPN split tunnels

When you open a VPN from a machine, the operating system will normally arrange that all network traffic (with the possible exception of the directly connected LAN) is routed through the tunnel. If the primary purpose of the tunnel is to reach machines inside the CUDN, this may not be desirable. It leads to ordinary web browsing traffic, for example, being routed into the CUDN and back out again, a phenomenon sometimes known as tromboning. Although not usually harmful, it is inefficient and may sometimes have unwelcome consequences.

If you wish to avoid this, you need to set up a split tunnel. This allows you to choose which traffic is routed through the tunnel and which should be sent out direct as if there were no tunnel. This requires some manual configuration of IP addresses, and is therefore an advanced topic.

The usual requirement is that machines on the CUDN should be accessed through the tunnel, and everything else direct. Although there are a large number of address ranges in use on the CUDN, for practical purposes it is usually sufficient to route the three main "class B" networks: 128.232.0.0/16, 129.169.0.0/16 and 131.111.0.0/16. If you need to reach "CUDN private" addresses you may also need to include 172.16.0.0/12 and 10.128.0.0/9. (This is slightly simplified; more details may be found elsewhere.)

The details of how to set up a split tunnel depend on the operating system. Normally you will need to remove the default route that sends traffic over the tunnel and replace it with explicit routes for the address ranges you want to be tunnelled. Hints for particular operating systems are given in the following sections.

Windows

The following instructions have been tested on Windows 7 Professional, but should work on any recent version.

  1. The first step is to set up a standard tunnel and ensure that it works.
  2. You now need to remove the default route:
    • From the Control Panel, go to the "Network and Sharing Centre", and then the "Change Adapter Settings" page. You should have a set of items for the various network adapters on the system, both real and virtual. Identify the one which relates to the VPN - it will have the name you gave it. You might wish to make a copy of the item and work on the copy under a different name, so that you can later choose between opening an ordinary tunnel and a split tunnel.
    • Open the property sheet of the VPN adapter.
    • Select the "Networking" tab.
    • Select the line "Internet Protocol Version 4 (TCP/IPv4)".
    • Click "Properties".
    • In the window that pops up, click "Advanced...".
    • In the next window, the tab "IP Settings" should be selected already. Untick the box "Use default gateway on remote network".
    • Click "OK" multiple times to close the cascade of windows.
  3. Open the modified VPN. It is important that the VPN is open for the next steps to work properly. Remember the name string that you gave to the VPN; the following example assumes that it is "VPN no gateway".
  4. Open a Windows Command shell or Windows PowerShell as administrator. This is normally done by finding the item in the start menu, right clicking and selecting "Run as administrator".
  5. Create a permanent route for each of the address ranges that you want to go over the tunnel. For the 3 main address blocks the commands would be:
    netsh interface ipv4 add route 128.232.0.0/16 "VPN no gateway"
    netsh interface ipv4 add route 129.168.0.0/16 "VPN no gateway"
    netsh interface ipv4 add route 131.111.0.0/16 "VPN no gateway"
    
  6. Open and close the VPN as you wish. The routes you have just created will survive across a reboot, but will only be active when the VPN is open.

Notes

You can test whether the split tunnel is working as you expect by using the tracert command to selected names or IP addresses. If the target is not tunnelled you should see that the first few hops are in your ISP's network. On the other hand if the target is tunnelled, the first reported hop will be end point of the VPN in the csi.cam.ac.uk domain, followed by other CUDN routers; the hops through your ISP etc will be hidden by the tunnel.

The route settings appear to apply to all VPNs of the same type, even though they have different names. If you have icons for both the generic CUDN and the CL VPN, you only need to create the routes once. This could create a problem if you also use an unrelated VPN service which requires a different split. If you cannot find a split that works for both you will need to write scripts to add and remove routes as you require.

If you have both an ordinary and a split tunnel, the former will still work as it should. The explicit routes will still be added to the routing table but cause no harm.

When you open a UIS VPN tunnel, Windows will start using the CUDN and/or CL DNS servers for name resolution, regardless of whether or not the IP addresses of those servers are themselves routed through the tunnel. Normally this is harmless, or even beneficial if you want to resolve CUDN-private names. In the unlikely situation that you would nevertheless prefer to use the DNS server associated with your local connection, Windows does not make it easy. A registry tweak that may be used to achieve it is described here. Use this at your own risk.

Ubuntu Linux

The following notes apply to Ubuntu Desktop 14.04 LTS with the VPN configured according to the UIS recommendations. Similar techniques are likely to apply to other Linux-based systems, though the details are likely to be different.

When the VPN is opened, all traffic is sent through the tunnel. Even connectivity with other machines on the local network is lost. This happens because the VPN configuration uses policy-based routing and applies it to all traffic. The actual mechanism is that the VPN setup creates an IP rule which directs all traffic to a replacement routing table which is not shown by traditional commands such as netstat -r. This routing table forces all traffic to be sent with the source address of the tunnel, which in turn triggers an IPsec security policy which causes the traffic to be encapsulated and sent through the tunnel.

This default behaviour can be influenced by modifying routing table 220, which exists only while the VPN is open. It can be manipulated by using the ip route command and adding the parameter table 220 to the subcommands.

Useful changes are to:

  • Add a route for the local network, corresponding to the one present in the main routing table.
  • Remove the default route sending traffic through the tunnel.
  • Add explicit routes for the addresses that should be tunnelled.

When the VPN is closed, routing table 220 disappears and the main routing table is used once more.

A script splitroutes may be downloaded from ...tba... to automate the necessary changes. It has been tested on a simple system with a single local network connection and may require modification for more complex configurations. The script should be run (as superuser) after opening the VPN. By default it will cause the VPN to be used for the three Cambridge "class B" address blocks; this may be overriden on the command line (see the comments at the top of the script itself for command line arguments).

The configuration changes are discarded when the VPN is closed.

Notes

You can test whether the split tunnel is working as you expect by using the traceroute command to selected names or IP addresses. If the target is not tunnelled you should see that the first few hops are in your ISP's network. On the other hand if the target is tunnelled, the first reported hop will be end point of the VPN in the csi.cam.ac.uk domain, followed by other CUDN routers; the hops through your ISP etc will be hidden by the tunnel.

The changes made by the script are equally applicable to the generic CUDN VPN and the CL-specific variant. The only practical difference between the two is the range from which the tunnel's IP address is taken.

Opening a VPN will normally cause your machine to start using CUDN and/or CL DNS servers for name resolution regardless of whether or not the IP addresses of those servers are themselves routed through the tunnel. Normally this is harmless, or even beneficial if you want to resolve CUDN-private names. In the unlikely situation that you would nevertheless prefer to use the DNS server associated with your local connection, you have two choices. The obvious method is to edit /etc/resolv.conf to contain the resolvers you want (but bear in mind that NetworkManager is likely to put it back at some point). The second method is to edit the VPN configuration, and under the "IPv4 Settings" tab, change the "Method" value from "Automatic (VPN)" to "Automatic (VPN) addresses only". If you do this, opening the VPN will not change the resolver configuration, but a likely consequence of this is that name resolution may not work at all until you run the splitroutes script to reinstate connectivity to the resolver.