Do you have to connect to a VPN in order to work? Do you need to connect to more than one VPN to work? Have you ever connected to a VPN that broke your Internet connection? VPNs are great, but static routes and DNS servers can really ruin your day sometimes. Recently, I had to connect to my work’s corporate VPN and from there had to connect to a separate internal VPN to access an environment I was working on (don’t ask). While connecting to multiple VPNs in and of itself is not an issue in my case I quickly learned that I did not have the connectivity I needed to access the environment through the second VPN.
What was happening and how can you fix it?
A VPN connects you to one or more private networks over a secure tunnel. Typically, VPNs push static routes to your local computer so your computer knows how to get to these new networks. The most common issue with static routes is when a static route overlaps with an existing static route on your local computer. It is easier to highlight this point through an example:
$ > netstat -rn | grep 172.16 172.16/15 192.168.0.1 UGSc 3 6 tun0 172.16 link#8 USc 0 62 jnc0
In the above example you can see static routes defined on my local system specific to the 172.16 network. The first output represents a static route over a TUN interface and was the route I needed to access the environment I mentioned above. The second output represents a static route over a Juniper interface and was specific to my corporate connection. As you can see there is some overlap between the two static routes. So which one wins? The easiest way to check is to run a traceroute to a host in the overlapping route:
$ > traceroute 172.16.0.1 traceroute to 172.16.0.1 (172.16.0.1), 64 hops max, 52 byte packets 1 172.31.5.1 (172.31.5.1) 1.722 ms 0.909 ms 6.765 ms ...
All you need to care about is the first hop in the traceroute. If the first hop connects to the gateway you expect then you should be good. In my case that gateway was 192.168.0.1. In the above test you can see I was getting routed to 172.31.5.1. If you run an ifconfig you should see that the jnc0 interface was connected to 172.31.5.1 thus confirming the issue.
The leaves the question of why was the corporate route winning? At first you might be tempted to say that the first route defined always wins, but that is not the case. The route that wins is always the most specific route. Since 172.16, which is equivalent to 172.16/16, is more specific than 172.16/15 it wins. So how do you fix it? One option is to remove the more specific route if possible. If possible means you do not need the route to access something else and that you can remove it. If you need the route for something else then you are stuck. The only way around this issue is to NAT the IP to some non-overlapping IP (outside the scope of this post). If you can remove a static route depends on how the static route was configured. Typically, if the second entry in the static route (i.e. the gateway) is an IP address or the word “default” then you can remove it. If the entry says “link#” then it likely cannot be removed (enforced by a VPN policy). Since in my case the more specific route was not the one I wanted it looked like I was stuck.
Two options to get around my particular issue are as follows:
- Client-side: Add a more specific route to access the environment. While you can not have two identical routes going to two different locations, you can publish more specific routes to get the access you need.
- Server-side: Push a more specific route in the VPN profile. If you have access to the server or can request a change to the server you can ask for more specific routes to be pushed. Depending on your environment this may be a more viable solution if this issue will impact a large number of people.
So what are the more specific routes needed to fix my issue?
$ > sudo route add 172.16.0.0/17 192.168.0.1 $ > sudo route add 172.16.128.0/17 192.168.0.1 $ > sudo route add 172.17.0.0/16 192.168.0.1
WARNING: Some versions of the route command include the -p flag to make a route persistent across reboots. I would not advise doing this as the route may be incorrect when you are off the VPN and could prevent you from accessing something that you need.
NOTE: One other thing you may notice about the static routes I care about is that their gateway points to 192.168.0.1. I bring this up because you may be on a LAN in that network (e.g. your home network). If this is the case then you may have connectivity issues due to the overlapping IP space.
© 2013, Steve Flanders. All rights reserved.
