You see what's going and also it is clear how inactivity timeout set by ping-restart is involved here.įor this to not happen, you have to carefully manage your VPN CA.

(2) misses some pings, decides the connection died and reconnects, now (1) won't receive pings.

(1) misses some pings, decides the connection died and reconnects, now (2) won't receive pings.(2) authenticates server sees the same certificate, so it thinks it was just replaced connection, and (1) will not receive keepalive pings anymore.This is often the sign that there are more that one client who are using this key/certificate pair: How can I debug this and figure out why the connection isn't being kept alive? Specifically adding ping/ping-restart to the client config doesn't seem to help (I assume it would be overridden by the server PUSH anyway). What am I missing? Is there a setting on the client that stops the ping from being sent to the server properly?

The 2 minute timeout makes sense given the ping-restart 120 setting pushed to the client, but I'm not clear why it thinks it has been inactive. Nothing really in the server log other than a connection restarting. Client log states: 11:40:26.121900 Inactivity timeout (-ping-restart), restarting However the connection always dies after about 2 minutes. Upping the log level on the client, it does look like the connection is sending data packets: 11:31:21.848620 UDP WRITE to. (note specifically ping 10,ping-restart 120) I have no problem connecting to other VPN servers, but this one seems to time out/reset every 2 minutes. I have an OpenVPN server running on Ubuntu in AWS, and using Tunnelblick on macOS to connect to it.

Tunnelblick openvpn