openvpn chroot does not have a valid resolv.conf

[Jason Gunthorpe]

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.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[grheard (grheard)]

Same problem here. I have had this problem since installing Ubuntu 16.04. This did not happen with Ubuntu 14.04.

Nov 22 09:35:58 GSOLT-3G2DTY1 nm-openvpn[6553]: [] Inactivity timeout (--ping-restart), restarting
Nov 22 09:35:58 GSOLT-3G2DTY1 nm-openvpn[6553]: SIGUSR1[soft,ping-restart] received, process restarting
Nov 22 09:36:00 GSOLT-3G2DTY1 nm-openvpn[6553]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 22 09:36:00 GSOLT-3G2DTY1 nm-openvpn[6553]: RESOLVE: Cannot resolve host address: vpn.xxxx.org: Temporary failure in name resolution
Nov 22 09:36:05 GSOLT-3G2DTY1 nm-openvpn[6553]: message repeated 2 times: [ RESOLVE: Cannot resolve host address: vpn.xxxx.org: Temporary failure in name resolution]
Nov 22 09:36:10 GSOLT-3G2DTY1 nm-openvpn[6553]: RESOLVE: Cannot resolve host address: vpn.xxxx.org: Temporary failure in name resolution
Nov 22 09:37:05 GSOLT-3G2DTY1 nm-openvpn[6553]: message repeated 11 times: [ RESOLVE: Cannot resolve host address: vpn.xxxx.org: Temporary failure in name resolution]

This continues until the VPN is turned off and then back on in the Network Manager applet.

[valerio (anziolin)]

creating a correct <chroot>/etc/resolv.conf does not appear to solve as later a failure executing up/down script is logged, probably for the same reason, missing necessary commands in chrooted environment

Feb 5 19:04:56 gubuntu nm-openvpn[10195]: [myserver.vpn.net] Peer Connection Initiated with [AF_INET]300.380.432.561:1300
Feb 5 19:04:58 gubuntu nm-openvpn[10195]: Preserving previous TUN/TAP instance: tun0
Feb 5 19:04:58 gubuntu nm-openvpn[10195]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --bus-name org.freedesktop.NetworkManager.openvpn.Connection_8 --tun -- tun
0 1500 1558 10.10.0.36 255.255.0.0 restart
Feb 5 19:04:58 gubuntu nm-openvpn[10195]: WARNING: Failed running command (--up/--down): could not execute external program
Feb 5 19:04:58 gubuntu nm-openvpn[10195]: Exiting due to fatal error

[Paul Crawford (psc-sat)]

I am seeing this with 64-bit 14.04.5 (even though 'grheard' did not have this problem with 14.04) using OpenVPN via the network manager. Seems to happen independently of DHCP renewals as several were logged before this last bit:

Feb 23 19:31:03 paul-ubuntu dhclient: DHCPREQUEST of 192.168.1.100 on eth1 to 192.168.1.1 port 67 (xid=0xacb31f1)
Feb 23 19:31:03 paul-ubuntu dhclient: DHCPACK of 192.168.1.100 from 192.168.1.1
Feb 23 19:31:03 paul-ubuntu dhclient: bound to 192.168.1.100 -- renewal in 1379 seconds.
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> (eth1): DHCPv4 state changed renew -> renew
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> address 192.168.1.100
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> prefix 24 (255.255.255.0)
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> gateway 192.168.1.1
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> hostname 'Desktop'
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> nameserver '192.168.1.1'
Feb 23 19:31:03 paul-ubuntu dbus[1306]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Feb 23 19:31:03 paul-ubuntu dbus[1306]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Feb 23 19:34:32 paul-ubuntu nm-openvpn[2357]: [server] Inactivity timeout (--ping-restart), restarting
Feb 23 19:34:32 paul-ubuntu nm-openvpn[2357]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 23 19:34:34 paul-ubuntu nm-openvpn[2357]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 23 19:34:54 paul-ubuntu nm-openvpn[2357]: RESOLVE: Cannot resolve host address: <redacted>: Temporary failure in name resolution

This fault continued through several more DHCP renewals until I manually reset the link:

Feb 23 23:04:11 paul-ubuntu nm-openvpn[2357]: message repeated 502 times: [ RESOLVE: Cannot resolve host address: <redacted>: Temporary failure in name resolution]
Feb 23 23:04:26 paul-ubuntu nm-openvpn[2357]: RESOLVE: signal received during DNS resolution attempt
Feb 23 23:04:26 paul-ubuntu avahi-daemon[1439]: Withdrawing workstation service for tun0.
Feb 23 23:04:26 paul-ubuntu NetworkManager[1577]: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/tun0, iface: tun0)

So manually disconnecting and reconnecting the VPN works, but is obviously not a satisfactory solution for machines that are normally unattended or if you wish to maintain privacy!

System details:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

$ apt-cache policy openvpn
openvpn:
  Installed: 2.3.2-7ubuntu3.1
  Candidate: 2.3.2-7ubuntu3.1
  Version table:
 *** 2.3.2-7ubuntu3.1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3.2-7ubuntu3 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

[Brett Keller (blkeller)]

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 ...