When doing OpenVPN over OpenVPN the route to the inner / 2nd VPN endpoint is using the wrong gateway / device
Agreeably it's not an everyday use-case to establish a OpenVPN connection across an existing OpenVPN connection. But when doing so, I ran into an issue with the host route pointing to the 2nd / inner VPN gateway ...
- Starting off clean, no VPN established, my routing table looks like this:
# ip route
default via 192.168.179.1 dev wlp3s0 proto dhcp metric 600
192.168.179.0/24 dev wlp3s0 proto kernel scope link src 192.168.179.2 metric 600
- After establishing the first OpenVPN session the routing table is updated:
# ip route
default via 10.100.56.1 dev tap0 proto static metric 50
default via 192.168.179.1 dev wlp3s0 proto dhcp metric 600
10.0.0.0/19 via 10.100.56.1 dev tap0 proto static metric 50
000.113.000.94 via 192.168.179.1 dev wlp3s0 proto static metric 600
192.168.179.0/24 dev wlp3s0 proto kernel scope link src 192.168.179.2 metric 600
192.168.179.1 dev wlp3s0 proto static scope link metric 600
The VPN endpoint is behind IP 000.113.000.94
(redacted) and there is now a default route via the VPN.
Certainly the host route towards 000.113.000.94
and via the regular default GW 192.168.179.1
is added to keep VPN traffic functioning - All this works just as expected.
- When establishing another OpenVPN session now (which happens successfully) the routing table looks like this:
# ip route
default via 10.100.56.1 dev tap0 proto static metric 50
default via 192.168.179.1 dev wlp3s0 proto dhcp metric 600
10.0.0.0/19 via 10.100.56.1 dev tap0 proto static metric 50
000.113.000.94 via 192.168.179.1 dev wlp3s0 proto static metric 600
192.168.179.0/24 dev wlp3s0 proto kernel scope link src 192.168.179.2 metric 600
192.168.179.1 dev wlp3s0 proto static scope link metric 600
10.3.4.5 dev tun0 proto kernel scope link src 10.3.4.6 metric 50
10.100.56.0/22 dev tap0 proto kernel scope link src 10.100.56.66 metric 50
10.100.253.157 via 192.168.179.1 dev wlp3s0 proto static metric 600
In this case the VPN endpoint is behind 10.100.253.157
and a host route is also added for it.
But unfortunately this route does not point to the already established vpn and the corresponding default gateway, but rather the regular default gateway that is present on the system prior to establishing any VPN.
The issue here is rather to distinguish between two independent VPN connections and a second tunnel that runs across an existing VPN. But since the other VPN already provides a default route with a better metric and the endpoint for the second VPN is reached this way to setup the new tunnel, it seems only natural to then also use the corresponding interface / gateways for the host route.
In my case I simply deleted the route (ip route del 10.100.253.157
) and voila the inner tunnel works just as expected since the traffic is then carried via the default route and across the first VPN.
This issue does NOT occur when establishing the connection "manually" via openvpn, only when using the imported configuration with the NetworkManager and the OpenVPN plugin.