0

I'm using Ubuntu 16.04.2 LTS and have observed that when I bring up a VPN connection with the GUI (server is openvpn), I get a host route added to the VPN gateway, in addition to the route to the VPN subnet. I've got the options "Ignore automatically obtained routes" and "Use this connection only for resources on its network" both selected.

Here's what my routing table looks at at first:

$ ip route show | grep -v linkdown
default via 192.168.1.1 dev wlp2s0  proto static  metric 600 
192.168.1.0/24 dev wlp2s0  proto kernel  scope link  src 192.168.1.184  metric 600 

Now I bring up a VPN connection, and I get:

$ ip route show | grep -v linkdown
default via 192.168.1.1 dev wlp2s0  proto static  metric 600 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.4  metric 50 
52.90.159.97 via 192.168.1.1 dev wlp2s0  proto static  metric 600 
192.168.1.0/24 dev wlp2s0  proto kernel  scope link  src 192.168.1.184  metric 600 

The new route for 10.8.0.0/24 makes sense to me, because that's the VPN subnet, but why do I also get a route for 52.90.159.97 (the VPN gateway)?

So far, it's just mysterious, but if I now bring up a second VPN that tunnels over the first VPN, I've got a real problem:

$ ip route show | grep -v linkdown
default via 192.168.1.1 dev wlp2s0  proto static  metric 600 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.4  metric 50 
10.8.0.2 via 192.168.1.1 dev wlp2s0  proto static  metric 600 
10.9.0.0/24 dev tun1  proto kernel  scope link  src 10.9.0.2  metric 50 
52.90.159.97 via 192.168.1.1 dev wlp2s0  proto static  metric 600 
192.168.1.0/24 dev wlp2s0  proto kernel  scope link  src 192.168.1.184  metric 600 

The second VPN gateway is 10.8.0.2 and, as you can see, the new host entry routes over wlp2s0, which is wrong (it should be tun0). I have to manually delete this entry to make the connection usable.

Maybe I should file this as a bug, but I'd like to hear any feedback here first.

1 Answer 1

0

After thinking about this for a few weeks, I've concluded that this is done to prevent any routes obtained over the VPN from matching the VPN gateway itself, creating a loop where the kernel is trying to route over the VPN to reach the VPN gateway. The most obvious case is if you acquire a default route over the VPN.

So, in my case, I'm now convinced that this is a bug. The logic makes sense, but has to be applied more intelligently. Maybe add a route to the VPN gateway only after checking that you would otherwise route gateway traffic over the VPN.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .