Stuck VPN After a Router Reboot: Three Things That Changed

The router finishes booting, the laptop rejoins the same SSID, and the VPN sits at connected with nothing moving. The saved profile is intact. What expired underneath it was the path, and the client is still holding the state it built for the old one.

Three conditions decide the fix. Check them in order, because the later ones are wasted effort if the first one already explains the stall.

Condition One: Did the Local Address Change

A reboot can hand the machine a different address. A VPN configured with a fixed local endpoint then keeps using an attachment that no longer exists. The same applies to a client that bound its socket to the old address. The tunnel interface can stay up while every packet it produces goes nowhere useful.

Compare the address the client is using with the address the interface currently holds. A default route that points at a gateway which has also changed is the same class of problem wearing a different name.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Condition Two: Is the Translated Mapping Gone

Home routers translate outbound flows, and those mappings live in memory. A reboot clears every one of them. That is harmless for a new connection and fatal for a tunnel that believes its existing flow is still valid. The peer then sees nothing, so the client never receives an error it can act on.

This is where a tunnel without keepalives stalls silently rather than failing loudly. WireGuard's documented limitations describe the same shape of failure. Wrong endpoint state produces dropped packets rather than a diagnostic.

A persistent keepalive of 25 seconds is the usual mitigation, because it refreshes the mapping before an idle timeout can expire. It does not repair a mapping that is already gone. Pair the keepalive with reconnection logic rather than treating it as a fix.

Condition Three: Did the Public Address Change

If the router's own external address changed, anything on the far side that filters by source address now sees a different peer. The tunnel may come up and the server may still discard the traffic, which looks like a broken client and is actually a policy on the other end.

Record the external address before and after the reboot. When the two differ, the question moves from the client to whoever maintains the allowlist, and resetting credentials on the laptop cannot help.

Recover in the Right Order

Complete any required captive-portal sign-in first, then let the client reconnect through its supported procedure rather than killing the process. Watch whether identity and data traffic both recover, because those are two different stages of the same connection.

A cached page proves nothing, and neither does a chat app that reconnected on its own. Test the endpoint you actually care about with a fresh request. Keep the direct-traffic policy in force during the interruption, since a reconnect attempt is not a block.

When this repeats after every reboot, the record matters more than the retry. Note the local address, the gateway, the external address and the client state before and after, then compare the two columns. That turns a vague complaint into a lifecycle bug somebody can fix, and it stops the certificates from being replaced for a third time over a mapping timeout.