Two Second Freeze: Was It the VPN or the Wi-Fi?
A two-second stall and a new VPN session are different events. Put the access path and the tunnel on separate timelines before you change a timer.
A two-second freeze that recovers looks identical whether the tunnel renegotiated or the radio hiccuped. It is also possible that nothing dropped at all, and that possibility is worth testing first. A short loss burst, a renegotiation and an application stall all feel the same to the person typing. Only one of the three is fixed by editing the tunnel configuration.
Keep Two Records, Not One
Write down what happened to the connection underneath, and separately what the tunnel itself did. Then place the application's pause against both records. Those are independent series of events that sometimes coincide, and calling all three a disconnect assumes the answer at the start.
A monitor that probes once a minute cannot see a two-second interruption. Reporting that day as healthy is technically accurate and practically useless. Put the sampling interval next to every result you quote.
What the access link did while the app froze
The sampling interval and the timeout define what the monitor could possibly have observed, so record both beside the result. A recorded absence of outages means little when the instrument samples every sixty seconds. Then probe three places with timestamps: the local router, an approved outside host reached over the plain path, and a resource behind the tunnel.
Confirm the routes first, because a public target can itself be routed through the tunnel and then measures the tunnel rather than the access path. The evidence that actually dates the outage lives a layer down: link events on the router, resync records on the modem, and a WAN address that changed. A cumulative error counter tells you that something went wrong, never when. Correlate those records with the incident window instead of reading them in isolation.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showA counter that rose yesterday explains nothing about a freeze this morning. Time-box the correlation to the window the user reported.
Look for the restart record
A dropped UDP datagram does not, on its own, make Community OpenVPN start a new TLS negotiation. Restart behaviour follows ping-restart, and the value in force may have been pushed by the server; the 2.6 manual defines those timers. Delivery breaks for a moment, the threshold is never crossed, and the log stays empty. So grep the log around the pause for a restart line, a fresh connect, or a session identifier that changed. If none of the three appears, the tunnel probably did nothing and the timer was never the problem.
Trimming every keepalive makes detection look quicker and moves the line where a blip becomes a reconnect. Each reconnect costs an authentication round and route reinstallation. Stretching the timer buys nothing except a longer window in which a dead path still looks alive. Both are tuning decisions with a price, not free improvements.
An absent event is evidence too, and it is the kind people skip because nothing in the log draws attention to it. Record the search you ran, not only its result.
Let the comparison decide what to fix
With both records side by side, the assignment usually writes itself. A router link event on both paths means the access connection is the subject. A quiet tunnel and a usable plain path mean the negotiation is.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Every row is a lead, not a verdict: endpoints deprioritise ICMP, and two destinations do not necessarily share a path. Keep clocks aligned across client, gateway and application so the comparison is even possible. A row that fits two columns needs one more observation, not a decision.
A report that survives review answers four things: how long the freeze lasted, which paths kept answering, what the tunnel logged at that second, and how often the monitor samples. Those four facts let the next reader reproduce the observation instead of trusting a summary. An uptime percentage hides exactly the interval you care about, and so does the phrase "the VPN dropped".