I encountered this same problem on Ubuntu MATE 16.04.2.
Every time the OpenVPN connection attempted to automatically restart
itself, it was unable to do so. This breaks the connection until a
manual restart of the connection through the NetworkManager GUI.
This bug is easily reproducible by sending the openvpn process a signal to
restart itself:
$ sudo killall -SIGUSR1 openvpn
Watching syslog and using strace on the process show it is unable to properly
restart because of lack of privileges and being jailed in the chroot
environment.
As others have mentioned here, I tried adding more and more dependencies
into the chroot, but after a while it just got ridiculous,
unmaintainable, and never actually fixed the problem.
*The following workaround does fix the problem for me.*
NetworkManager attempts to run openvpn as an unprivileged user and in a
chroot. Normally, this is a good security practice, but the
implementation unfortunately is half-baked. The openvpn man page calls
out several problematic cases in which dropping privileges or chrooting
can cause failures on connection restarts, and both the man page and
official how-to seem lukewarm at best on the added security benefits.
The benefits are even less clear for a client-only configuration as
opposed to a server. A reasoned cost/benefit analysis for my own use-
case shows the costs of dropping privileges and/or chrooting when
running openvpn outweigh the benefits, at least at this point in time
(02/2017).
While disabling NetworkManager and running openvpn manually or as a standalone
service is a valid solution for running openvpn as root, there are other
benefits to running NetworkManager on a desktop or laptop system that I don't
want to give up. However, getting NetworkManager to play nice is not trivial.
As of late Sep. 2016, NetworkManager changed their default behavior with regard
to openvpn, forcing it to always run with least privileges:
https://github.com/GNOME/network-manager-openvpn/commit/03fc318608b0d60decaced38e0de7a74c2ac5c4c
As mentioned in the source code, the only way to override this default is by
setting a few environment variables with null values. The cleanest way to do
this is to create a drop-in systemd configuration file for NetworkManager:
1. Create the directory to hold the drop-in configuration file:
$ cd /etc/systemd/system
$ sudo mkdir NetworkManager.service.d
$ cd NetworkManager.service.d
2. Create a new conf file:
$ sudo nano disable-openvpn-reduced-privileges.conf
3. Add the following content to the file:
# Disable NetworkManager's OpenVPN plug-in from performing chroot and
dropping privileges by default (null assignment)
[Service]
Environment="NM_OPENVPN_CHROOT="
Environment="NM_OPENVPN_USER="
Environment="NM_OPENVPN_GROUP="
4. Save the file and exit nano
5. In order for the changes to take effect, you may either restart the
NetworkManager service and quit & restart your openvpn connection, or if it is
simpler for you, just restart your computer.
You can test if this is working properly several ways:
1. Systemd should show that the drop-in configuration is in use:
$ systemctl status NetworkManager
NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service;
enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/NetworkManager.service.d
+-disable-openvpn-reduced-privileges.conf
2. When openvpn is running it should be running as the root user. This can be
verified using ps or any other process lister/monitor.
3. Force a running openvpn connection to restart and see if it is successful:
$ sudo killall -SIGUSR1 openvpn
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager-openvpn in Ubuntu.
https://bugs.launchpad.net/bugs/1586570
Title:
openvpn chroot does not have a valid resolv.conf
Status in network-manager-openvpn package in Ubuntu:
Confirmed
Bug description:
If you leave openvpn running for long enough it will eventually begin
to fail with output like:
May 27 19:16:54 wakko nm-openvpn[16480]: RESOLVE: Cannot resolve host
address: XXXX: Temporary failure in name resolution
Analysis shows this is because openvpn is sending DNS queries to
127.0.0.1:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 8
connect(8, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=8, events=POLLOUT}], 1, 0) = 1 ([{fd=8, revents=POLLOUT}])
sendto(8, ..., 30, MSG_NOSIGNAL, NULL, 0) = 30
However, this is not correct, dnsmasq listens on 127.0.1.1.
It appears the a cause of this is the chroot, the chroot has no
resolv.conf in it and the glibc default is to use 127.0.0.1
openvpn does a DNS query before chroot'ing which used to be enough to
cache resolv.conf forever. I wonder if something has changed in glibc
recently to cause the resolv.conf to be reloaded (eg Debian apparently
has a patch that does this)
A work around would be to copy the system resolv.conf into
/var/lib/openvpn/chroot before starting openvpn
Seen on Xenial and a few prior versions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1586570/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
