openvpn client can't reconnect after server failure

[lameventanas]

In a routed vpn when the server is restarted the client can't re-establish the vpn and the client's openvpn exits. If I manually restart the openvpn process in the client, it works again.
Both systems run openvpn as a non-priviledged user.
Same behavior occurs with 2.1.1, 2.2.1 and 2.2.2.

It seems that the client detects that the server is gone and tries to restart (ping-restart), but can't configure the interface anymore because it already dropped root privileges at this point.
The client is configured with persist-tun, persist-key, persist-local-ip and persist-remote-ip, and the configuration is not changed in any way between server restarts, so it shouldn't need to recreate the tun/tap device.

This is the client's log when the server restarts, I replaced hostnames, IPs and port numbers:

20:52:47-05:00 vpn-client[20616]: [server.domain.com] Inactivity timeout (--ping-restart), restarting
20:52:47-05:00 vpn-client[20616]: SIGUSR1[soft,ping-restart] received, process restarting
20:52:49-05:00 vpn-client[20616]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
20:52:49-05:00 vpn-client[20616]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
20:52:49-05:00 vpn-client[20616]: Re-using SSL/TLS context
20:52:49-05:00 vpn-client[20616]: LZO compression initialized
20:52:49-05:00 vpn-client[20616]: TCP/UDP: Preserving recently used remote address: x.x.x.x:x
20:52:49-05:00 vpn-client[20616]: UDPv4 link local (bound): [undef]:x
20:52:49-05:00 vpn-client[20616]: UDPv4 link remote: x.x.x.x:x
20:52:53-05:00 vpn-client[20616]: [server.domain.com] Peer Connection Initiated with x.x.x.x:x
20:52:55 manage_link: No such device or address
20:52:55-05:00 vpn-client[20616]: Preserving previous TUN/TAP instance: tun0
20:52:55-05:00 vpn-client[20616]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
20:52:55-05:00 vpn-client[20616]: ERROR: Linux route delete command failed: external program exited with error status: 7
20:52:55-05:00 vpn-client: Last message 'ERROR: Linux route d' repeated 1 times, supressed by syslog-ng on client.domain.com
20:52:55-05:00 vpn-client[20616]: /sbin/ifconfig tun0 0.0.0.0
20:52:55-05:00 vpn-client[20616]: Linux ip addr del failed: external program exited with error status: 255
20:52:56-05:00 vpn-client[20616]: Note: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
20:52:56-05:00 vpn-client[20616]: Note: Attempting fallback to kernel 2.2 TUN/TAP interface
20:52:56-05:00 vpn-client[20616]: Cannot allocate TUN/TAP dev dynamically
20:52:56-05:00 vpn-client[20616]: Exiting

[Samuli Seppänen]

Does someone know if there's a way to fix this with some configuration options? Or does OpenVPN really try to run privileged operations (e.g. add routes) if it has to reconnect to the server?

[JoshC]

The function do_up() in init.c will force the tun device to re-open if the md5 digest of the pulled options changes, even when persisting the tun interface. The most common thing that would cause that would be a new client IP, which will require elevated permission to set (as well as remove the routes bound to that gateway, at least in net30 mode.)

I don't see a clean way around this issue when the pushed options change. At the very least, some external script would need elevated permission to do the actual interface address change, including removing the old IP and setting the new one. Same for routes, and writing logic to catch all the places where elevation is required to do each action and checking for an active script for those hooks seems to be the wrong solution here.

My recommendation is to increase the verbosity to show the PUSH_REPLY string to see what exactly is triggering the tun re-open. If it's just the IP, use of --ifconfig-pool-persist on the server should help keep clients attached to the same IP. If non-IP pushed options change, I think that can just be expected to break clients using --persist-tun in the general case.

[Samuli Seppänen]

I think JoshC's suggestion makes sense. Setting milestone to 2.4, revert if it does not make sense.

[Gert Döring]

This is basically unfixable - if the server sends us options that need privileges to set up (mtu, ip config, routes) and we can't, no way around. verb 3 would help understanding which option exactly changed between one PUSH_REPLY and the nxt.

That said, with 2.6, we actually can handle this on Linux, by keeping the NET_ADMIN privileges even if going to an unprivileged users. Yay :-)

Still closing as "wontfix", as this is not really a bug but just the way permissions work - if you give them away, they are gone.