OpenVPN restart breaks connection

Question

I use a VPN (PIA installed by this method) on Ubuntu 16.04 through the default Network Manager. Frequently--after around 5 minutes of streaming or ~1 hour of normal browsing--it is cutting out, by which I mean everything fails, including direct connections to a given IP.

After digging through /var/log/syslog, I found this sequence of events, which seems to be the culprit:

Apr  8 17:41:43 ***** nm-openvpn[9107]: [83d27bda14f33782df085b09962c2dfa] Inactivity timeout (--ping-restart), restarting
Apr  8 17:41:43 ***** nm-openvpn[9107]: SIGUSR1[soft,ping-restart] received, process restarting
Apr  8 17:41:45 ***** nm-openvpn[9107]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Apr  8 17:41:45 ***** nm-openvpn[9107]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr  8 17:41:45 ***** nm-openvpn[9107]: RESOLVE: Cannot resolve host address: us-east.privateinternetaccess.com: Temporary failure in name resolution
Apr  8 17:42:20 ***** nm-openvpn[9107]: message repeated 8 times: [ RESOLVE: Cannot resolve host address: us-east.privateinternetaccess.com: Temporary failure in name resolution]

Sometimes it is preceded by this:

Apr  8 10:47:28 ***** nm-openvpn[4716]: TLS Error: Unroutable control packet received from [AF_INET]*.*.*.*:**** (si=3 op=P_CONTROL_V1)
Apr  8 10:47:56 ***** nm-openvpn[4716]: message repeated 3 times: [ TLS Error: Unroutable control packet received from [AF_INET]*.*.*.*:**** (si=3 op=P_CONTROL_V1)]

However, everything I found about this indicates a time synchronization issue, which I don't have.

Here's the openvpn process spawned by Network Manager:

/usr/sbin/openvpn --remote us-newyorkcity.privateinternetaccess.com 1194 udp --comp-lzo --nobind --dev tun --auth-nocache --reneg-sec 0 --syslog nm-openvpn --script-security 2 --up /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --bus-name org.freedesktop.NetworkManager.openvpn.Connection_8 --tun -- --up-restart --persist-key --persist-tun --management /var/run/NetworkManager/nm-openvpn-b0ce41de-070b-42c7-af39-90961791ebeb unix --management-client-user root --management-client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec --client --auth-user-pass --ca /etc/openvpn/ca.crt --user nm-openvpn --group nm-openvpn --chroot /var/lib/openvpn/chroot

(I can't find where in NM to change any of these options...)

Any idea where the problem may be?

Answer 1

Recently had the same issue and came across this post on bugs.launchpad.net & it fixed it for me! Detailed post is here, but I'll go ahead and list the instructions out.

In short, OpenVPN is unable to reconnect due to a permissions issue. (It always is, isn't it!?)

You'll need to create a Drop-in "plugin" for systemd.

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

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="

Save the file and exit nano. 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:

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. I personally use htop.

3. Force a running openvpn connection to restart and see if it is successful:

$ sudo killall -SIGUSR1 openvpn