Encountering the following problem – OpenVPN works perfectly when started or restarted, but when the network connection of the computer restarts or for example, the WIFI device resets (or loses the wifi network and connects again when it becomes available) the VPN never recovers. All networks routed via the VPN never seem to work again and they become dead ends to the computer despite the Internet connectivity is OK.
The logs show only attempts to connect again to the servers, but apparently with no success:
.... Oct 13 02:22:55 www openvpn: Attempting to establish TCP connection with [AF_INET]18.104.22.168:12345 [nonblock] .... Oct 13 02:24:55 www openvpn: TCP: connect to [AF_INET]22.214.171.124:12345 failed: Connection timed out .... Oct 13 02:22:55 www openvpn: Attempting to establish TCP connection with [AF_INET]126.96.36.199:12345 [nonblock] .... Oct 13 02:24:55 www openvpn: TCP: connect to [AF_INET]188.8.131.52:12345 failed: Connection timed out
The server 184.108.40.206 is unreachable and it stays unreachable even the network connectivity recovered and the Internet of the computer is OK.
In this case, the OpenVPN server is part of a route network push to the client, and the OpenVPN IP is part of the pushed network to be routed via the VPN. And when the client’s network connection resets, the additional server’s IP route to the gateway disappears, but the pushed route does not, and now the OpenVPN server’s IP is part of a VPN route, which is dead because the VPN channel is dead. A restart of all OpenVPN routes is required (remove the special VPN device tun device with its routes and then add the device and routes again after successful reconnection to the OpenVPN server), but when an OpenVPN client option persist-tun is in the configuration, the restart won’t happen in the mentioned way. Only a restart of the service will remove the tun and its routes and then add them after a successful reconnection to the OpenVPN server.
Removing the persist-tun from the client’s configuration will trigger a full restart of the VPN channel – remove the special tun device and all OpenVPN routes and then reconnect and initialize the special tun device and then add the pushed routes.
Here is the example:
- The OpenVPN server’s IP is 220.127.116.11.
- The OpenVPN server pushes several networks to the client. Networks, which must be routed via the VPN. One of them happened to be 18.104.22.168/24, which includes the OpenVPN server’s IP.
- The OpenVPN server adds a route for its IP to be routed via the default client’s gateway, which is 192.168.0.1. This is how the VPN channel works despite it pushed the whole network 22.214.171.124/24 via the VPN.
The problem appears when the network resets and the client’s OpenVPN process removes the route for the OpenVPN IP via the gateway because the gateway is not valid anymore! With persist-tun the pushed OpenVPN routes won’t be removed only reconnect attempts will be tried. But the OpenVPN IP now routes via the pushed server’s route via the dead VPN channel.
Keep on reading!