WAN IP changed and the tunnel dropped: the checks in order

The tunnel drops, the router logs a reconnect, and nothing on the LAN moved. A new WAN address invalidates the outer connection without changing anything inside: the client's source address changed, the old NAT state points at a source that no longer exists, and the remote peer may still be sending to the previous address. Recovery is normal behaviour, and the useful question is which state failed to update.

Name the event before you read the log

Check what actually happened at the access layer. An ISP lease renewal is one event. A PPPoE session that reconnected is another. A fibre modem that rebooted, or a WAN failover from one uplink to another, changes the outer address or its path in a third way. They are not the same event and they do not leave the same residue.

A reconnect line in the VPN log is also not proof of a WAN change. An idle timeout, a reauthentication interval and dead-peer detection all produce reconnects with no address change at all. Compare timestamps from the access log with the VPN log before concluding anything, and keep the comparison window wide enough to catch a change that happened during the night.

Roaming and reconnecting are different protocols

WireGuard has authenticated roaming built into the protocol: when a peer receives a correctly authenticated packet from a new source address, it updates that peer's endpoint. The WireGuard quickstart describes the peer configuration that makes this work, which is why a client on a changing address often recovers without a visible restart.

OpenVPN behaves differently by default. A UDP session can end and reconnect, and the optional float behaviour allows an authenticated peer to continue from a new address where the configuration permits it. TCP-based tunnels are stricter, because the connection itself is tied to the address pair. That difference decides whether the recovery looks invisible or announces itself in the log every time.

Neither behaviour says anything about the applications inside. A recovered tunnel does not restore a TCP session that the peer already considered dead.

State the tunnel does not own

Translation and routing state survive the reconnect in ways that surprise people. A conntrack entry created for the old source keeps the reply path anchored to an address that no longer exists, and it expires on its own schedule rather than when the tunnel came back. Restarting the tunnel service does not shorten that wait, so a repaired link can still look broken for a while.

Routes and policy rules can reference the old gateway or interface. A rule set that was correct before a WAN switch may point at a device that is now down, which produces a tunnel that reports as connected and traffic that goes nowhere. Dynamic DNS for a server you host is a separate problem from a client acquiring a new source. The record needs updating for remote clients to find you, and no client-side configuration compensates for an address that upstream translation will not forward.

Order the Checks From the Outside In

The order below runs from the outer connection inward, and stopping at the first failing step is what makes it useful: each pass rules out the layer above it. Keep that order even when the fault looks obvious.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

The first command shows the current endpoint and handshake age for each peer. The second and third show whether the outer interface and the route to the endpoint still make sense. The conntrack count is a coarse check for state left over from the previous address, and the journal is where the reconnect reason is recorded.

Then test from a LAN client rather than from the router. A ping sourced by the router itself uses a different path from forwarded traffic, so a successful router ping proves the tunnel exists and nothing about client reachability.

Decide the expected behaviour and write it down

Reconnecting is correct behaviour for most deployments, so the goal is not to prevent it. Decide instead what should happen to traffic during the gap: stop it, hold it, or fail over to another path. That decision belongs in the firewall and routing policy, not in the VPN profile.

Record the access events and the reconnect times together for a week. Repeated changes with no matching access event point at the access service, and replacing the VPN profile will not fix an uplink that keeps renegotiating. A single pair of entries in the same minute settles the question for that incident and gives the next one a baseline.