VPN Keeps Disconnecting? Work Through It in This Order

Before you reinstall the client, write down three things: how long the tunnel stayed up, what the client said when it dropped, and whether the machine slept or changed networks in between. That note is the only evidence you will have later, and reinstalling usually erases it. A drop at a repeatable interval is a timer or a state expiry; a drop at a random moment is a path problem. The order below keeps you from changing three things at once and learning nothing.

Step one: capture the interval and the error text

Start with the client's own log rather than the vendor dashboard. On a Linux client, the service log plus the live tunnel state covers most of it:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Record the timestamps of the last successful handshake and the moment traffic stopped, not just the moment the icon changed colour. A GUI client that says disconnected after the fact may be reporting a state the kernel reached seconds earlier.

Keep the wording of the error. A timeout, an authentication rejection and an adapter or driver error point at three different layers, and most of the wasted effort in this problem comes from treating them as one. Copy the line verbatim into your note.

Step two: change one variable, not the profile

Keep the device and the profile fixed and move the machine to a different access network, such as a phone hotspot. This is the cheapest test that separates the client from the path. Run it long enough to cover the original failure interval; two stable minutes prove nothing about a drop that happens at minute thirty.

A laptop with an Ethernet port gives you a second comparison that removes Wi-Fi from the picture entirely. If the tunnel holds on both alternatives, the original access network deserves the attention: access point roaming, a consumer router expiring its translation table, or an upstream link that resets long-lived flows.

Write down which variable you changed. A comparison only counts when everything else stayed the same, and that includes the server endpoint and the time of day.

Step three: map the interval to a layer

The length of a good session is the most informative single number you have. Read it against this list before touching timers:

• Drop after sleep or resume: the tunnel state survived the suspend but the interface did not. Check the client's reconnect-on-resume behaviour and whether the service restarts the tunnel or waits for traffic.
• Drop only when idle: something in the middle expired the flow. This is the case keepalives exist for.
• Drop at a fixed session age: a reauthentication or rekey event, not a path failure. An explicit rejection in the log at that exact interval is the tell.
• Drop during large transfers or large pages: suspect MTU and fragmentation, not an idle timer.

For the idle case, the settings are protocol-specific and both ends matter. OpenVPN's keepalive 10 60 on the server pushes a ping every 10 seconds and restarts the link after 60 seconds without one; WireGuard clients behind NAT use PersistentKeepalive = 25 in the peer block. OpenVPN also renegotiates the data channel on a timer, reneg-sec, which defaults to 3600 seconds in 2.x.

Do not copy aggressive values from another provider's guide. A short timeout on a lossy mobile link produces the disconnects it was supposed to prevent, and pushed server values override what you set in the client profile.

Step four: compare one supported alternative

If the operator publishes both a UDP and a TCP profile, run the same device and network against the other one. Use the actual matching file rather than editing the transport in a copied profile. A stable TCP profile on a path where UDP resets narrows the problem to that path; it does not prove TCP is the better transport everywhere.

The same logic applies to endpoints. Try one other server and keep the original result next to it. If only one exit resets sessions, that is evidence about that endpoint, not a reason to rebuild every adapter on the laptop.

After any switch, repeat the original trigger and confirm where traffic actually goes. Regained internet access is not the same result as traffic inside the tunnel, and a client that silently fell back to a direct route looks healthy from the browser.

Verify the fix, and keep the rollback

A fix is verified by reproducing the original trigger, not by a successful connect. Leave the tunnel idle past the old failure interval, suspend and resume once, and check the handshake age and the exit address afterwards:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Keep the previous profile and the previous timer values until the new behaviour survives a full working day. If the drops return, restore the backup, then reapply one change at a time so the second attempt starts from a known state.

If the log stays clean and the tunnel still drops at a repeatable interval, the next stop is the server side for that session. Take the client's session identifier and the exact drop time with you, because that pair is what makes a server log searchable. The protocol's link options are documented in the OpenVPN 2.6 manual when you need the exact semantics of a value.