OpenVPN Client: unable to reconnect after server line disconnect
-
I use OpenVPN to connect to a server behind a static IP on a DSL line. Even though the IP is static, the DSL needs to be reconected once ever 24h for "technical reasons".
The problematic behaviour: after the OpenVPN client loses connection, it is not able to reconnect. Even when I force a disconnect and even when I quit the client and restart it, it cannot connect again.
I have the same problematic behavior when restarting the pfSense, e. g. after maintenance.
Diagnosis: Another machine is able to connect at the same time without issues (which is why I concluded it is a client issue).
Also, when normally losing network connectivity, e. g. on my side, the client is able to reconnect again in a totally fine way.
Is there some way around this? It is rather bothersome to have to restart the local machine, just to make OpenVPN client work again.
(Though, thruth to be told, I am used to even worse behaviours off other VPN clients, that even totally break network connectivity on errors, recoverable also only through system restart.)
-
Have to see logs stating why it cannot connect.
-
So.. finally, same situation again - this just does not happen often.
This is the client output.
Wed Aug 16 20:36:46 2017 TLS Error: TLS handshake failed
Wed Aug 16 20:36:46 2017 SIGUSR1[soft,tls-error] received, process restarting
Wed Aug 16 20:36:48 2017 UDPv4 link local (bound): [undef]
Wed Aug 16 20:36:48 2017 UDPv4 link remote: [AF_INET]80.XXX.XXX.247:1194
Wed Aug 16 20:37:48 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Aug 16 20:37:48 2017 TLS Error: TLS handshake failed
Wed Aug 16 20:37:48 2017 SIGUSR1[soft,tls-error] received, process restarting
Wed Aug 16 20:37:50 2017 UDPv4 link local (bound): [undef]
Wed Aug 16 20:37:50 2017 UDPv4 link remote: [AF_INET]80.XXX.XXX.247:1194
Wed Aug 16 20:38:50 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Aug 16 20:38:50 2017 TLS Error: TLS handshake failed
Wed Aug 16 20:38:50 2017 SIGUSR1[soft,tls-error] received, process restarting
Wed Aug 16 20:38:52 2017 UDPv4 link local (bound): [undef]
Wed Aug 16 20:38:52 2017 UDPv4 link remote: [AF_INET]80.XXX.XXX.247:1194I had to restart the client PC for the connection to work again. Even closing and reopening the OpenVPN client did not help at all.
-
Interestingly, I came here looking for help on a very similar problem, and this topic was at the top the list. How often does that happen?
My connection is a little different, but the results the same. My pfsense router is connected to a comcast modem, and operates as an OpenVPN client to Private Internet access. Most of my network traffic routes through the VPN, with selected items using the straight WAN. Lately my comcast connection has been dropping out. This a separate issue (#I_HATE_COMCAST), but what's key is that after these disruptions the VPN is not reconnecting. I know the modem is working because I can connect to my Synology NAS, which uses the WAN. I cannot, however, connect to either PC which are being routed via the VPN. Sometimes resetting the modem remotely will restore full communication, but sometimes it does not. My modem disconnected at least 5 times today. The first few times resetting the modem restored the VPN, but on the 4th one the VPN never came back, although I could see my NAS.
With all the fun I had today I have loads of log data, but it's way too much to copy and paste here. Is there a way to download the logs?
If not, I guess I can cut and paste the log data into a text file. Either way, any ideas which logs would be most helpful trying to help? I'm thinking the OpenVPN and System/General logs plus maybe the System/Routing log.
-
Looks like the client couldn't reach the server for whatever reason. You would have to look at the logs on the server to see what was happening at the same time. Or maybe even packet capture on the server to see if the attempts were arriving.
If they are not being delivered to the interface there is nothing the server can do about it.
-
The problem was solved by rebooting the client.. so I would guess the OpenVPN client is bad. Or could it be some issue on the server side?
I mean, the client IP stays the same.. I don't know if anything would survive on the server side, in this case I rebooted the server, and it reconnected on the same IP and opened VPN access again.
