VPN Dead After Sleep: Dropped Tunnel or Stale App?

The lid opens, the wireless icon comes back, and the VPN still shows as connected. The first internal page then hangs until it times out, and a new tab does the same. Three different things can produce that picture, and they need three different fixes: a tunnel that did not survive the sleep, a profile that nothing asked to reactivate, or an application still holding a session that died hours ago. Comparing them is faster than reinstalling anything.

Three things can be broken after wake

The first candidate is the tunnel itself. The interface may still exist with an address while the peer association is gone, which is why an indicator light is not evidence of a working path. A handshake older than the sleep is the tell, and it takes one command to see.

The second is activation. Many clients reconnect on their own; some do not, and a profile that is not asked to come back will sit there looking configured. That failure is silent by design, because nothing errored.

The third is the application. A browser tab, an SSH session or a database connection can survive a network change as a file descriptor while the transport underneath it is dead. A new session then works perfectly, which tells you the tunnel was fine all along.

Compare the three before changing anything, because the fixes do not overlap. Restarting a client that was never asked to start again wastes the evidence you needed. Write down which candidate the symptom fits before you touch a configuration. That one sentence usually decides the rest of the investigation.

First: did the tunnel come back?

Look at the interface and the peer state rather than at the client's own status text. An interface with an address and no recent handshake is a tunnel that is up in name only.

ip -brief addr show
wg show
ip route show table all | head -20

If the interface is missing entirely, the tunnel did not survive and the question becomes who was supposed to bring it back. If it is present but the handshake is old, the peer relationship needs re-establishing and the client may be waiting for traffic to trigger it.

Check the routes and the DNS configuration too. A tunnel can return without its routes, which produces the confusing state where the interface is up and internal names still resolve through the wrong server.

Second: did anything ask it to come back?

This is where the comparison earns its keep. An OpenVPN plugin profile and a native WireGuard connection are handled differently by NetworkManager, and the connection settings reference is explicit that connection.autoconnect does not activate VPN profiles; the mechanism for bringing a VPN up with a connection is connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

If a manual reconnect repairs the problem every single time, that is the signature of a missing activation rather than a broken tunnel. The log will usually show the interface going down and nothing bringing it back.

Resist the urge to add a sleep hook immediately. A hook that fires before the network has recovered races the very process it is trying to help, and it turns a reproducible problem into an intermittent one.

Third: is the application holding old state?

Open a brand new session to the same destination before you touch the VPN. If the new session works and the old one does not, the tunnel is fine and the application is holding a dead connection.

This is the cheapest of the three checks and the one most often skipped, because the failing window is right there on screen. Close it, reopen it, and note whether the problem survives. If the new session works, stop investigating the tunnel entirely. If it fails too, the application is a symptom rather than a cause.

Some applications recover on their own after a timeout, which is why the symptom can appear to fix itself after a few minutes. That behaviour points at the application rather than at the tunnel, and it is worth recording separately. A colleague who reports "it just fixed itself" is describing this pattern, not a lucky break.

Make the comparison reproducible

Keep the variables small: one access network, one sleep duration and the same first request each time. Then log two results: whether reconnecting by hand repairs it, and whether another sleep brings the failure back.

That last observation is the one that separates the three candidates most reliably. A working new session after a failed old one is not a tunnel problem, and no amount of client reinstallation will change it.

WireGuard's persistent keepalive belongs in this picture only as a NAT mapping keepalive. It sends packets to hold a mapping open; it does not stop the machine from sleeping and it cannot keep sending while the process is suspended.

Record what you found in the ticket: which of the three was broken, what repaired it and how you reproduced it. The next person to open a lid on a Monday will thank you, and the answer will not have to be rediscovered from scratch.