VPN Drops After a DHCP Renewal? Compare the Addresses

Lease renewal and VPN failure appear together in logs often enough that people conclude one causes the other. The timing is real; the causality usually is not. A renewal is a unicast request to the server that issued the lease, asking to continue using the same binding, and the server can extend it without the client changing a single address. Walking the client's own values around the event separates a lease that renewed quietly from a network that genuinely changed underneath a running tunnel.

Start From the Client That Dropped

Open the client's connection log first and note the time of the drop to the second. Then open the operating system's network log for the same minute and read what the interface did, in order. This ordering is the whole investigation: a DHCP event before the disconnect, a disconnect before the DHCP event, and two events with nothing between them are three different findings. A log line that merely mentions the lease while the tunnel was already reconnecting is decoration, not evidence.

Write the timeline down as you go rather than holding it in memory. Timestamps from different tools rarely align perfectly, and the offset itself is sometimes the explanation.

Compare the Four Values Around the Event

Four values describe the local side of a connection well enough to catch a real change: the interface address, the default gateway, the resolver list and the interface's operational state. Capture them within a minute after the drop and compare with a capture taken while the tunnel was healthy.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

An unchanged address with an unchanged gateway and a changed resolver list points at name resolution rather than routing, and the tunnel may have survived while applications stopped finding hosts. A changed gateway means the path out of the local network moved, which is enough to invalidate a route that pointed at the previous one. If all four values match the healthy capture, the lease is not your cause and the client's own reconnect logic becomes the subject. Capture the comparison while the fault is visible, because a healthy capture taken after a reboot has a different address history and will not match.

What a Renewal Can and Cannot Change

RFC 2131 describes renewal as a request to the original server at half the lease time, with rebinding to any server at seven eighths if the first attempt goes unanswered. Neither step requires the client to acquire a different address, and a cooperative server normally extends the existing binding. A real address change usually arrives through a different path: a server refusing the renewal, a client that lost its state and started over, or a network that moved the device to a different segment.

The public side of the connection can change with no local change at all. Behind carrier-grade translation, the address the VPN peer sees may be reassigned independently of anything the local lease did, and that reassignment looks identical to a local network failure from inside the client. Comparing a locally reported address with a peer-side observation is the only way to separate them.

When the Client Fails to Adapt

A client that bound its transport to the old address, cached a stale route to the peer, or saved an interface identity may keep retrying a path that no longer exists. That is an adaptation defect, and it is visible as repeated retransmissions toward an address the host can no longer reach. Some clients handle it by design: WireGuard, for instance, updates a peer's endpoint when a correctly authenticated packet arrives from a new source.

A manual restart that restores service is a clue about where adaptation failed, not proof that leases and tunnels are incompatible. Keep the blocking policy in place while testing, or the test itself becomes an outage with a different cause. Record whether the client recovered on its own, how long it took, and which address it retried; that sequence tells you more than the disconnect reason shown in the interface.

Repeat the Event Before You Blame It

Reproduce the condition rather than waiting for the schedule: release and renew the lease, or force the equivalent controlled event, and watch whether the tunnel survives. On a managed network, coordinate any address change with the network owner, because an arbitrary static assignment can collide with a device that already holds that address.

After a supported fix, repeat the same event and then test an application and a name lookup, since a tunnel that reconnects but breaks DNS passes a weaker test than the one that matters. Report the specific change you observed, with its timestamp, instead of naming the scheduled lease as the cause. The difference between those two reports is whether the next person can reproduce the fault or only the rumour.