GNOME Bugzilla – Bug 787824
DHCP configuration without default gateway will not allow NM managed VPN clients to connect
Last modified: 2020-11-12 14:29:49 UTC
Setup: RHEL 7.4 with these packages: NetworkManager-1.8.0-9.el7.x86_64 NetworkManager-openvpn-1.2.6-1.el7.x86_64 NetworkManager-openvpn-gnome-1.2.6-1.el7.x86_64 openvpn-2.4.3-1.el7.x86_64 NetworkManager is configured to use DHCP with manually configured routes. The aim here is to be able to get a connection which only can connect to an external VPN server and pass all the network traffic via that VPN tunnel. The manually configured routes is to be able to access DNS servers and VPN server only. Starting OpenVPN from the command line (or via systemd) works fine. But the NetworkManager VPN integration does not start the connection as it claims it is lacking network connectivity - which is only partially true. This is somewhat similar or related to bug #750412, but this setup does not configure a default gateway at all. Example configuration: ------------------------------------------------------------------ nmcli> print ipv4 ['ipv4' setting values] ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: (default) ipv4.dns-priority: 0 ipv4.addresses: -- ipv4.gateway: -- ipv4.routes: { ip = 46.39.203.0/20, nh = 192.168.8.1, mt = 10 }; { ip = 195.70.160.0/19, nh = 192.168.8.1 } ipv4.route-metric: -1 ipv4.ignore-auto-routes: yes ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-timeout: 0 ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.never-default: yes ipv4.may-fail: yes ipv4.dad-timeout: -1 (default) ------------------------------------------------------------------
NM treats VPN connections special. VPNs require an underlying device, which NM chooses by taking the "best" device. That is the device with a default route. If no device has a default route, NM fails the activation. Tying the VPN to a particular device does not make sense in many cases. This should be improved ... (todo)
It is reasonable that _some_ VPN clients must have a functional underlying device configured. For OpenVPN that is not a strict requirement for running OpenVPN; you only need a functional route to the remote server to establish the VPN. If that route is missing or it otherwise cannot reach the remote server, it will try to reconnect at some predefined intervals. That means that OpenVPN could give a far better user experience if the NM-openvpn integration did not have a hard requirement on a functional interface with a default route. If switching between LAN and WLAN, between different WLANs or mobile connections, it will today most commonly disconnect the VPN connection. This can be avoided completely if OpenVPN is allowed to continue to run. If connecting to an OpenVPN 2.4 server, this will not even re-trigger a full tunnel renegotiation; the client connection will just float to the new public IP address seamlessly (based on the Peer-ID field in the OpenVPN wire protocol). This is a very handy feature for laptops. NM should learn to trust OpenVPN and don't try to micromanage OpenVPN. If the OpenVPN process stops running, that's when the tunnel truly is considered down.
(In reply to David S. from comment #2) I agree.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).