Kubuntu network-manager-openvpn not routing traffic via VPN server

Question

I have an OpenVPN config file which works great from the terminal:

sudo openvpn --config openvpn.conf

After connecting via the terminal, my routing table is as follows:

[van@d2:Desktop]$ ip route
0.0.0.0/1 via 255.255.255.0 dev tun0 
default via 192.168.0.1 dev wlp3s0 proto static metric 600 
10.9.0.1 via 255.255.255.0 dev tun0 
<vpn_server_ip_addr> via 192.168.0.1 dev wlp3s0 
128.0.0.0/1 via 255.255.255.0 dev tun0 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.5 metric 600 
255.255.255.0 dev tun0 proto kernel scope link src 10.9.0.4

I wanted to try and get things working from the Network Manager, so I installed network-manager-openvpn and then imported the VPN connection from the working config file. However, when I connect using the Network Manager, traffic is not routed via the OpenVPN server. The routing table (after connecting using the Network Manager entry) is as follows:

[van@d2:Desktop]$ ip route
default via 192.168.0.1 dev wlp3s0 proto static metric 600 
10.9.0.0/24 dev tun0 proto kernel scope link src 10.9.0.4 metric 50 
<vpn_server_ip_addr> via 192.168.0.1 dev wlp3s0 proto static metric 600 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.5 metric 600 
192.168.0.1 dev wlp3s0 proto static scope link metric 600

I have tried to add the 0.0.0.0 entry (from the working routing table), but it is rejected:

[van@d2:Desktop]$ sudo ip route add 0.0.0.0/1 via 255.255.255.0 dev tun0 
RTNETLINK answers: Network is unreachable

I have also tried removing:

10.9.0.0/24 dev tun0 proto kernel scope link src 10.9.0.4 metric 50

and replacing it with:

10.9.0.1 via 255.255.255.0 dev tun0 

but this also fails with a similar error message (the removal worked).

My question is: how can I connect to an OpenVPN server via the Network Manager and force all traffic to be routed via the VPN tunnel?

Answer 1

I have found a "solution" (and I use this term very loosely here) based on this post: Network Manager does not set IP4.GATEWAY for OpenVPN connection - although I'm convinced this is a bug with the network-manager-openvpn module.

The problem occurs because no gateway is set for the OpenVPN tunnel:

[van@d2:~]$ nmcli device show tun0
GENERAL.DEVICE:                         tun0
GENERAL.TYPE:                           tun
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     tun0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/15
IP4.ADDRESS[1]:                         10.9.0.4/24
IP4.ADDRESS[2]:                         192.168.0.7/32
IP4.GATEWAY:                            --
IP6.ADDRESS[1]:                         fe80::cd28:e3cf:f9e6:1417/64
IP6.GATEWAY                             --

The default gateway can be obtained using:

[van@d2:~]$ ip route
default via 192.168.0.1 dev wlp3s0 proto static metric 600 
...

Now use nmcli con show to obtain the UUID of the OpenVPN tunnel (tun0 in my case):

[van@d2:~]$ nmcli con show
NAME                UUID                      TYPE             DEVICE 
VAN-200-5GHz        <SOME-UUID>-9c79da9597a1  802-11-wireless  wlp3s0 
van                 <SOME-UUID>-484ee303d901  vpn              wlp3s0 
tun0                <SOME-UUID>-2a1a14674e78  tun              tun0   
Wired connection 1  <SOME-UUID>-d3935bcf886b  802-3-ethernet   --     

Once you have the UUID, set the gateway using:

nmcli con mod <SOME-UUID>-b717eca7a5a0 ipv4.gateway 192.168.0.1

Now check to make sure you're using the VPN Server's IP address:

dig @resolver1.opendns.com myip.opendns.com +short
<YOUR-VPN-SERVER-IP>

One of the side effects of using this method is you'll end up with a "zombie" connection every time you add a tun0 gateway (and these will persist across reboots):

[van@d2:~]$ nmcli con show
NAME                UUID                      TYPE             DEVICE 
VAN-200-5GHz        <SOME-UUID>-9c79da9597a1  802-11-wireless  wlp3s0 
Wired connection 1  <SOME-UUID>-d3935bcf886b  802-3-ethernet   --     
van                 <SOME-UUID>-484ee303d901  vpn              --     
tun0                <SOME-UUID>-c4381868f3f3  tun              --     
tun0                <SOME-UUID>-157870b81351  tun              --     
tun0                <SOME-UUID>-a1bc29fb7bef  tun              --

You can remove these using:

[van@d2:~]$ nmcli con del tun0
Connection 'tun0' (<SOME-UUID>-157870b81351) successfully deleted.
Connection 'tun0' (<SOME-UUID>-c4381868f3f3) successfully deleted.
Connection 'tun0' (<SOME-UUID>-a1bc29fb7bef) successfully deleted.

Considering how complicated it is working around these issues just to be able to connect to OpenVPN using the Network Manager, you're probably going to be far better off just connecting via the terminal (assuming you have a valid OpenVPN config file).

I'm not sure how to report bugs of this nature, so if anyone knows, please chime in.

Answer 2

Solved here with a simpler approach:

sudo nmcli connection modify vpnu-us-mia ipv4.route-metric 0 solves the issue

The metric of the default ethernet was 1, so setting to a lower value

Also ignored cipher restrictions:

sudo nmcli connection modify vpnu-us-mia +vpn.data tls-cipher=DEFAULT:@SECLEVEL=0 ipv4.route-metric 0