VPN Reconnected but the App Session Still Fails

The tunnel comes back, the client says connected, and the browser still spins on a page it was loading before the drop. A VPN reconnect restores a path, and it does not restore the connection state that applications and the remote side accumulated on the old one. Those are different things to repair, and confusing them sends you back into the VPN settings for no reason.

One test separates them cleanly, and it takes ten seconds. Send a new request to the same destination while the old one hangs.

What Survives a Reconnect and What Does Not

A tunnel is a set of routes, keys and addresses, and a reconnect can restore all three while every established flow stays dead. The operating system keeps a socket open because the application asked it to, and that socket's timeout may be minutes or hours away. Underneath, the peer has forgotten the flow, a translation entry has expired, or the path now runs through an endpoint that never saw the handshake. Nothing in the reconnect sequence walks the application's sockets and repairs them.

Some clients add a hook that drops stale connections on reconnect, and most do not. Behaviour here varies by client, platform and version.

The Remote Side Forgot You Too

The far end holds state of its own: a TLS session, a TCP control block, and possibly a mapping entry tying your address and port to the flow. A translation device along the path can expire that mapping during the gap even when the tunnel re-establishes quickly. Once the mapping is gone, packets arrive for a flow the server no longer recognises, and the reply may be a reset the client never surfaces. Applications report this as a stall rather than an error, because they are still waiting on a socket that will never answer.

Server-side idle timeouts do the same thing on their own schedule, which is why a session can die with no network event at all. A connection that was idle longer than the server expects is already gone before you notice the tunnel move.

A Fresh Request Is the Test That Separates Them

Send a new request to the same host while the old one still hangs, and watch both. If the new request succeeds, then the tunnel, the route and name resolution all work, and the fault is confined to the stale flow. If the new request fails too, you have a path problem and the application's session state is a red herring.

Keep any direct-traffic block in place during the test. A request that succeeds through an accidental fallback path proves nothing about the tunnel.

Confirm With a New Connection, Not the Old One

The commands below show the sockets still open, start one new request, and check whether the session table still holds an entry for the flow. Run the first one before and after the reconnect so the difference is visible. Replace the host and port with your own service.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

An established socket with no traffic moving is the signature to look for, and a new request returning a status code shows the path is alive. The connection table answers whether anything still maps the flow, which is the part the client cannot see. The resolver query covers the other half of a page load, since a name failure and a stalled connection look identical in a browser. Together those four outputs separate a stale session from a broken tunnel.

Record the interruption time, the reconnect time and the difference between the old request and the new one. That record turns a vague complaint into a report someone can act on.