Public IP Changed and the VPN Stopped Passing Traffic

An ISP reconnect or a change in upstream translation alters the public source of a VPN session, and the client's local private address usually stays exactly as it was. The tunnel then looks connected while nothing useful crosses it. Both observations are true at once, which is what makes the report confusing.

Work through the four checks in order, and stop at the first one that fails.

Which Address Actually Changed

Compare the local interface state with the source a remote endpoint observes, at a point where you are authorized to look. A new public address does not imply a new local gateway, and a local interface change does not guarantee the public source moved either. Translation in between means the two are independent facts. Record the exact path and the time you observed it, because a geolocation label copied from an old report answers a different question.

Ask specifically whether the outer source changed, the inner tunnel address changed, or both. Only the first one explains a peer that keeps sending to a path that no longer exists.

Let the Protocol Handle the Move

Protocols differ in how they learn that a peer moved, and the difference matters for whether you should intervene at all. WireGuard updates a peer's endpoint when it receives a packet that authenticates under that peer's key, which is why an address change can be absorbed without any configuration. IKEv2 has MOBIKE for the same purpose where both ends support it. Older designs recover by rebuilding the tunnel instead.

What you should not do is accept an unauthenticated message as proof that a peer's identity moved. A datagram claiming a new address is trivial to forge, and a client that believes it can be steered to an attacker's endpoint. The authenticated protocol is the mechanism; a notification is not.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Clear the Stale Outer Binding

When the protocol does support roaming and traffic still fails, the obstruction is often stateful equipment in the middle or a policy on the far end. A firewall that tracked the old flow may keep the stale entry, and a server-side access rule keyed to the old source will drop the new one silently. Cleaning the mapping and re-checking the rule is faster than replacing credentials.

Keep required blocking in force while you investigate. Opening the policy wide to test whether the tunnel recovers teaches you nothing about the cause and leaves the deployment worse than you found it.

Retest With a Fresh Request

An application session established before the change does not survive it, because the four-tuple it was built on no longer exists. Generate a new request after recovery and confirm it completes, rather than watching an old download sit at zero and concluding the tunnel is still broken. That single distinction resolves a large share of these reports.

Then record both halves of the diagnosis: what changed upstream, and which supported recovery step restored the flow. The next occurrence will be faster, and the note is what makes it faster.

If a fresh request succeeds and the old one never resumes, the tunnel was fixed and the application simply needs to reconnect.