After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 750873 - /usr/libexec/nm-openvpn-service-openvpn-helper handles restart in script wrongfully, resulting in lost routes
/usr/libexec/nm-openvpn-service-openvpn-helper handles restart in script wron...
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-06-12 18:31 UTC by Rolf Fokkens
Modified: 2016-07-04 08:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vpn: support option to preserve previous routing information on VPN config update (3.81 KB, patch)
2016-07-04 08:26 UTC, Thomas Haller
none Details | Review
src: preserve IP route configuration on restart (2.51 KB, patch)
2016-07-04 08:36 UTC, Thomas Haller
none Details | Review
src: preserve IP route configuration on restart (2.66 KB, patch)
2016-07-04 08:45 UTC, Thomas Haller
none Details | Review

Description Rolf Fokkens 2015-06-12 18:31:45 UTC
On Fedora 22:

Description of problem: Apparently since upgrading to Fedora 22 an openvpn connection restart (resulting from an openvpn server restart) results in lost (pushed) routes, but an otherwise succesful connection

Version-Release number of selected component (if applicable):
NetworkManager-openvpn-1.0.2-2.fc22.x86_64
openvpn-2.3.6-1.fc22.x86_64

How reproducible: 100%


Steps to Reproduce:
1. create a succesful VPN connection
2. restart the VPN server daemon
3. notice a restart of the connection
4. notice missing routes

Actual results:
connection without pushed routes

Expected results:
Functional connection based on all pushed routes

Additional info:
A workaround is this:
[root@home07 ~]# cd /usr/libexec/
[root@home07 libexec]# ls -l nm-openvpn-service-openvpn-helper*
lrwxrwxrwx. 1 root root    38 Jun 12 19:24 nm-openvpn-service-openvpn-helper -> nm-openvpn-service-openvpn-helper.wrap
-rwxr-xr-x. 1 root root 24264 May 28 11:34 nm-openvpn-service-openvpn-helper.orig
-rwxr-xr-x. 1 root root   171 Jun 12 19:42 nm-openvpn-service-openvpn-helper.wrap
[root@home07 libexec]# cat nm-openvpn-service-openvpn-helper.wrap
#!/bin/bash

( echo $0
  echo "$@"
  env ) > /tmp/`date +%s`.dump

eval [ "\${$#}" == "restart" ] && exit 0

exec `dirname $0`/nm-openvpn-service-openvpn-helper.orig "$@"
[root@home07 libexec]#
Comment 1 Rolf Fokkens 2015-06-12 18:32:16 UTC
For more details:

https://bugzilla.redhat.com/show_bug.cgi?id=1231338
Comment 4 Rolf Fokkens 2015-07-11 09:28:21 UTC
Hoping to speed up progress on this annoying issue a bit, some more details:

From the man page:

NOTE: on restart, OpenVPN will not pass the full set of environment variables to the script.   Namely,  everything  related  to routing  and gateways will not be passed, as nothing needs to be done anyway - all the routing setup is already in place.

I think this is where the issue is, see these lines in nm-openvpn-service-openvpn-helper.c:

        tmp = getenv ("ifconfig_local");
        if (!tmp && is_restart)
                tmp = argv[4];

This will recover IP settings, but not routing settings. So what happens is that IP addresses are sent to dbus/NetworkManager/whatever:

        /* Send the config info to nm-openvpn-service */
        send_config (connection, config, ip4config, ip6config);

Which apparently results in re-applying the IP addresses, while dropping the (pushed) routes in the process.

I hope this is helpful.
Comment 5 Thomas Haller 2016-07-04 08:26:59 UTC
Created attachment 330830 [details] [review]
vpn: support option to preserve previous routing information on VPN config update

On openvpn restart, the VPN helper script is invoked without full routing information.
Thus, the routes will be dropped because the helper script cannot provide them
on update.

Add an option "preserve-route" which tells NetworkManager to preserve
and reuse the previous configuration.

https://bugzilla.redhat.com/show_bug.cgi?id=1231338
Comment 6 Thomas Haller 2016-07-04 08:36:29 UTC
Created attachment 330832 [details] [review]
src: preserve IP route configuration on restart

During restart, openvpn does not provide the routing information to the
helper script. Make use of a new option to tell NetworkManager to re-use
the previous configuration.

The "preserve-routes" defines are obtained from the shared header file
"nm-vpn-plugin-macros.h" so that we don't have to bump required API.

https://bugzilla.redhat.com/show_bug.cgi?id=1231338
Comment 7 Thomas Haller 2016-07-04 08:45:43 UTC
Created attachment 330834 [details] [review]
src: preserve IP route configuration on restart

During restart, openvpn does not provide the routing information to the
helper script. Make use of a new option to tell NetworkManager to re-use
the previous configuration.

The "preserve-routes" defines are obtained from the shared header file
"nm-vpn-plugin-macros.h" so that we don't have to bump required API.

https://bugzilla.redhat.com/show_bug.cgi?id=1231338
Comment 8 Beniamino Galvani 2016-07-04 08:52:45 UTC
Patches LGTM.
Comment 9 Thomas Haller 2016-07-04 08:59:13 UTC
merged upstream:


NetworkManager: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=375d3e1cb89afb66f26d61f941551a37d94272ae

nm-openvpn: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=9e90d37abf6b3a02d487bf892fa926715cc1064e


Note that you both components (service and plugin) need the patches to fix the issue.