openvpn client can't reconnect after server failure

lameventanas

I am trying to make a routed vpn between two computers. Everything works well, but I noticed that when the server is restarted the client can't re-establish the vpn and openvpn exits. If I restart the openvpn process in the client, it works again.
Both systems run openvpn as a non-priviledged user.
The client runs 2.1.1 and the server 2.2.1.

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

Mimiko

First update the client to latest version.
As a work-around you can use --down script to restart the OpenVPN service.

lameventanas

Mimiko wroteFirst update the client to latest version.
As a work-around you can use --down script to restart the OpenVPN service.

I updated both client and server to 2.2.2, but still have the same problem, do you think this is a bug?

The --down work-around would require the script to be setuid root, so I would rather have this (bug?) solved instead.

Mimiko

This must not be a bug. Let wait for what developers have to say. Also you can set a cron job, which will ping the remote server and if ping fails - restarts the OpenVPN service.
Usually runing OpenVPN as non-privileged is not common, as OpenVPN is not as less secure as for example using the tunnel try to break the system.