Which NAT Hop Drops the Idle VPN Mapping, and How to Tell
An idle VPN flow can die at any stateful hop. Repeat one test, compare what each boundary saw, and report the bounded result instead of a guessed culprit.
After a quiet period the tunnel reconnects, nothing in any log names a culprit, and the obvious move is to pick the device with the most impressive timeout documentation. That is a guess dressed as a diagnosis. State can survive for a while in a home router, in a carrier translator and at a cloud edge, and any of them can drop a flow that goes quiet. What you can do instead is map the path, mark which devices you can actually observe, and run one idle test you can repeat.
A repeatable test converts an anecdote into a measurement. Everything below assumes one client, one server and one protocol, and it assumes you resist changing two variables at once. The point is to make the next occurrence cheaper than this one.
Run the same idle test every time
Write down when the flow was last known good, how long it then sat idle, and whether one fresh packet brought it back. Those three facts are the measurement; without them you have a story about a laptop that dropped. Use the same client, the same server and the same protocol on every repeat, and note the moment the first packet after the silence was sent.
Then compare what each boundary you own actually saw. The distinction that decides the investigation is whether the server saw nothing at all after the pause, or saw the request and answered into a path that no longer carried the replies.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Comparing paths without changing five things
A second approved access network is a legitimate comparison, because the NAT chain differs. It also differs in ISP, radio conditions and possibly address family, so the result is a boundary rather than an attribution. Record the limitations with the outcome instead of quietly dropping them when you report. Write the path down while you are at it: device, role, and whether its state can be read at all.
What a comparison of paths buys you is a constrained question: the flow survives on one and dies on the other after a similar silence, so the variable lives somewhere in the parts that differ. That is a real result even when no device is named, and it tells the next engineer where to spend an afternoon and where not to.
Local state is worth reading before you speculate about carriers. On a Linux gateway, conntrack -L lists the tracked flows with their remaining lifetime, which turns a guess about a timer into a number you can watch expire. Read it before and after the idle period, not only after.
What a keepalive will and will not hold
A supported keepalive holds a mapping open, and holding a mapping open proves nothing about the service behind it. The tunnel can stay mapped while the application it carries has stopped answering, and from a status light those two situations look the same. Treat a keepalive as insurance against idle expiry, not as a health check.
Set the interval against the shortest timeout you actually measured rather than a number copied from a forum. A keepalive tuned below every plausible timer is traffic nobody needed, and it also removes the symptom that would have told you which boundary expires first. Choose the interval from the measured number and leave everything else alone.
One change, then measure again
Resist the urge to raise every timeout and flush every gateway during a live test. That erases the evidence you came for and interrupts flows belonging to other people, which is a bad trade for a hypothesis you have not tested. Change one supported setting, on one device, then repeat the idle period and the application recovery.
Record which boundary observation moved, and record it even when nothing improved. A setting that fixed nothing is information, and it is cheaper to notice once than to roll across the estate.
Writing a finding you can defend
When an upstream translator cannot be inspected, say only what the evidence supports: the exchange dies somewhere along this stretch of the path after that much quiet, and the hop responsible remains unattributed. A bounded statement survives review and points the next person at the right segment. Naming a hidden router as the cause does neither. Hand the bounded finding to whoever owns the unobservable segment, with the interval attached.
RFC 4787 describes why UDP mapping timers are difficult to infer from one endpoint, and that difficulty is the reason the bounded finding is the honest one. Timers are real, and so is the uncertainty around them.