Home / ubuntu / Questions / 1297119
In Process
Florian Echtler
Asked: 2020-12-04 00:49:19 +0800 CST

OpenConnect VPN via NetworkManager: invalid default route, still using local gateway?

  • 772

I'm using network-manager-openvpn to connect to my university VPN. The VPN works when I just run openconnect -u username vpn.host.edu from the commandline (although it spews a lot of ip route error messages).

However, when starting the VPN through the NetworkManager GUI, the resulting routing table is messed up:

$ ip route
default via 192.168.178.1 dev enxXXXXXXXXXXXX
default dev vpn0 proto static scope link metric 50 
default via 192.168.178.1 dev enxXXXXXXXXXXXX proto dhcp metric 20100 
[...]

The first entry causes all traffic to still be routed through the local gateway. Consequently, e.g. name resolution with the VPN DNS servers fails and the VPN is unusable. When I remove the first routing table entry with ip route del default via 192.168.178.1 dev enxXXXXXXXXXXXX, then everything starts working as intended.

All network settings for the VPN connection are set to "Automatic", so why is the VPN entry not the first default route?

P.S. I know that there are workarounds described in Network Manager does not set IP4.GATEWAY for OpenVPN connection and Network Manager does not set IP4.GATEWAY for OpenVPN connection - but I would like to fix this without having to run a shell command everytime.

networking vpn network-manager openvpn

1 Answers

  1. Yes, as usual, I found the (more or less) solution 5 minutes after posting the question :-/

    It seems like this bug is related: https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/33#note_889793

    The linked comment suggests using a script in /etc/network/if-up.d/ to fix the routes, I'm using this for now.

    #!/bin/sh
# Hacky workaround bug in NM not setting the default routes.
if [ "$IFACE" = "vpn0" ]; then
  #ip route replace default via 0.0.0.0 dev vpn0
  ip route del default via 192.168.178.1 dev enxXXXXXXXXXXXX
fi

    I'd still like to see this fixed without hacky scripts, but apparently, it's a known bug.

    • 0