NetworkManager+OpenVPN seems to systematically fail at all possible levels to automatically reconnect to the configured VPN server after a ping-restart.

By systematically fail I mean:

1) When an address instead of an IP is used in the client configuration file ("remote") NetworkManager will fail to resolve the address because the connection to the DNS server is attempted to be made over the disconnected VPN tunnel.

2) If 1) is solved by either replacing the address with an IP, using "persist-remote-ip" or using a local DNS resolver (e.g. Unbound), connecting to the VPN server will still fail, because the connection is attempted to be made over the disconnected VPN tunnel -- key negotiation and all other attempts at communicating with the VPN server will obviously fail.

I think this could be fixed by either removing the tunnel route entirely or adjusting its metric when a ping-restart occurs, and reverting the changes after a successful connection. As long as this doesn't happen, I'd almost say that at least enabling "persist-remote-ip" should be the default behaviour -- because how else would NetworkManager manage to resolve the VPN address if no local DNS resolver is specified (and one is lucky enough that the TTL for the domain hasn't timed out)?

However even if this was the case, the actual issue of establishing a connection to the resolved VPN IP still exists.

Is this simply a configuration issue on my end? The configuration files I am using can be found here: https://www.privateinternetaccess.com/openvpn/openvpn.zip. An excerpt of the nm-openvpn log during a disconnect:

    16.06.16 19:07  nm-openvpn  [Private Internet Access] Inactivity timeout (--ping-restart), restarting
    16.06.16 19:07  nm-openvpn  SIGUSR1[soft,ping-restart] received, process restarting
    16.06.16 19:07  nm-openvpn  NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    16.06.16 19:07  nm-openvpn  UDPv4 link local: [undef]
    16.06.16 19:07  nm-openvpn  UDPv4 link remote: [AF_INET]46.166.188.193:1194
    16.06.16 19:08  nm-openvpn  TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    16.06.16 19:08  nm-openvpn  TLS Error: TLS handshake failed
    16.06.16 19:08  nm-openvpn  SIGUSR1[soft,tls-error] received, process restarting
    16.06.16 19:08  nm-openvpn  NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

The address could be resolved here because of my running Unbound instance, however actually contacting the server failed because of the still existing and disconnected VPN route.