VPN disconnects at the same interval? Match the timer
A drop at a fixed interval is a fingerprint. Compare the tunnel rekey, the NAT idle timer, the DHCP lease and the account limit before changing anything.
A tunnel that dies every fifteen minutes, or every hour at the same minute, is telling you that some timer expired rather than that the network is flaky. The useful move is to write the interval down and compare it with the four timers that produce this pattern. Changing timeouts before that comparison usually moves the failure without explaining it, which makes the next occurrence harder to read than the first. The measurement costs ten minutes and replaces a week of guessing.
Turn the interval into a number
Collect five or six occurrences and compute the gap between them, not the gap from the start of the day. A drop at 09:12, 10:12 and 11:12 is an hourly boundary; a drop at 09:12, 09:27 and 09:42 is fifteen minutes from the last successful connection. Round the result to the nearest plausible timer rather than to the nearest minute.
Record two moments per event: when traffic last moved and when the client reported the disconnection. Those differ when a tunnel dies silently and the client notices only on the next send, and the difference is what separates an idle timeout from a hard failure. A client that notices late inflates the idle window you measure.
Note whether the reconnect is automatic. A client that reconnects within seconds keeps the interval visible in the log and out of the user report, which is why these failures are often described as occasional rather than periodic. It also hides the event from the person who is using the laptop.
Four timers that look alike
Almost every repeating tunnel drop comes from one of these: a protocol rekey, an idle mapping expiry, a DHCP or interface event, or an account policy. They differ in whether traffic was flowing and in what the log says at the boundary.
The signatures below are worth learning, because they let you reject three explanations from a single log line:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
The first row is a security mechanism doing its job, and the second is a middlebox forgetting state. Confusing them leads to either weakening the rekey or chasing a firewall rule that was never involved.
Busy versus idle tells you which half
Run a controlled comparison with continuous traffic, such as a long stream to a host inside the tunnel, and watch whether the interval changes. If the drop disappears while data flows, the timer is idle-based.
If it survives continuous traffic, the trigger belongs to rekey, lease or policy. That single test removes half the candidates in about an hour of observation, and it costs nothing but attention.
Keep the access network unchanged during the test. Moving between Wi-Fi and Ethernet mid-comparison introduces exactly the interface event you are trying to distinguish from a timer.
Match the log line to the boundary
Read the client and server logs around the recorded moment, not the whole file. A rekey shows negotiation; an idle expiry shows nothing until the next packet; a lease change shows address work; a policy limit usually shows a clean administrative disconnect.
These commands pull the relevant window from each source:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showIf the three sources agree on the timestamp, you have the owner of the timer. If only the client log has anything, the server is probably not the one ending the session.
Fix the stage, not the icon
Each owner has one supported repair. A rekey failure needs compatible proposals on both ends. An idle expiry needs a keepalive or a shorter idle expectation, within what the path allows. A lease event needs the interface or power settings addressed. An account limit is a policy decision, not a bug.
Disabling rekeying or authentication to keep the icon green trades a visible drop for an invisible weakness, and it leaves you unable to say when the tunnel last negotiated fresh keys. Retest the original duration afterwards and keep the timestamps, so the next event can be compared with this one instead of starting over.