Fallback lease after the site tunnel returns: renew or wait?

Site link up, tunnel established, and the branch PCs still cannot reach the file server. Two clocks were running during the outage and only one of them has finished. The tunnel recovered when the encrypted path came back; each client's address recovers when its current lease ends or is replaced. Comparing those two timelines explains the gap faster than reading firewall logs.

Two clocks, and one of them is not the tunnel

With DHCP-over-VPN plus a local fallback, the device can hand out temporary local leases while the remote DHCP path is unavailable. The temporary duration is usually counted in minutes, which is short enough to hide the problem and long enough to outlive a brief outage. When the tunnel returns, the fallback stops offering those leases. It does not reach into a client and cancel the lease it already holds. That client keeps its address, mask, gateway and resolver until renewal or expiry, which is why a healthy tunnel and a broken desktop can coexist for the rest of the lease.

Keep the implementation and the software version attached to this statement. Timer names and default values differ between SonicOS releases, and an older interface does not prove what a newer one does.

Compare the two recovery moves

Move A is to wait. It costs nothing, risks nothing, and leaves each client to renew on its own schedule. Move B is to force a release and renew on the affected client, which gets the intended address immediately but interrupts everything the client is doing. On a single desktop, forcing the renewal is usually the faster path and easy to justify. On a lab or a point-of-sale terminal mid-transaction, waiting is the safer choice, and a scheduled renewal outside business hours beats both.

ipconfig /all
ipconfig /release
ipconfig /renew

Read the output before releasing anything. If the address, gateway and DNS already match the normal scope, the client recovered on its own and the remaining problem is somewhere else. On a Linux client the equivalent is a lease release and renew through the network manager rather than a hand-edited address, because the manager will otherwise rewrite your change at the next event.

Read the offer, not just the address

The address alone does not say who supplied it. What matters is the server identifier in the offer, the lease time, and whether the gateway and resolver match the fallback scope or the normal one.

tcpdump -ni any 'port 67 or port 68'

Capture during the renewal, because a quiet interface tells you the client never asked. If the offer comes from the local fallback while the tunnel is up, the selection logic is still treating the remote path as unavailable, and forcing renewals on clients will only repeat the same result. Correlate the capture with tunnel events on the same clock. A rekey or a brief drop that ends seconds before the client's request is a plausible cause; a clean tunnel with a fallback answer is a configuration problem in the selection path.

Where the comparison inverts

If many clients are affected at once, per-client renewals turn into a queue of interruptions and a support call. In that case, look at the fallback scope and the restoration procedure instead of the clients, because the population recovered together and will recover together again.

If only one client is affected while its neighbours are fine, the reverse holds: that client's lease, its reservation or its own DHCP client behaviour is the variable, and a site-wide change is the wrong tool.

Static addresses and reservations need a third answer. A client pinned to an address cannot be rescued by renewal, and a reservation that collides with the fallback scope produces a duplicate that looks like a routing fault until you compare the two address plans.

Write the exit procedure down

Decide in advance what the fallback is for, how long a client may keep its temporary address, and who is allowed to force a renewal during business hours. Write the answer where the on-call engineer will find it, next to the scope definition. Then test it once, deliberately: drop the tunnel, watch what the client receives, restore the tunnel, and record how long the client takes to get its normal settings back. That single exercise replaces most of the guesswork the next time the site link flaps.

Finish by confirming the resource, not the address. Reaching the file server, resolving its name and reaching the internet are three separate checks, and only the last one was never in doubt.