Why Your VPN Takes Longer to Recover Than the Outage

The Wi-Fi came back thirty seconds ago and the VPN is still down, so the client looks broken. Often it is following its own retry schedule, and that schedule does not know the network just returned. That gap is the whole story: recovery time is the outage plus whatever wait the client had already committed to. Lowering every timer is one response, and understanding which timer matters is the other.

Three conditions decide whether tuning helps: which stage is slow, whether the failure is retryable at all, and how the client learns that the network is back.

Three waits that look like one

Endpoint resolution, IKE or TLS negotiation, packet retransmission and starting a fresh attempt are separate events with separate timers. strongSwan documents retransmission backoff for IKE, and OpenVPN has its own retry controls with different semantics. Copying a number from one to the other assumes the mechanisms match, and they do not. Read the log sequence before you decide which interval you are looking at.

A silent minute in the log is not necessarily a frozen process. It may be an exponential backoff doing exactly what it was configured to do.

Which stage is actually slow?

If the log shows attempts failing with an authentication error, no timer change helps, because the credential is wrong. If attempts are not being made at all, the client is inside its wait window and the schedule is the fix. If attempts are made and time out, the problem is reachability or a missing listener, and retrying faster only fills the log. Each of those three states has a different owner, and only one of them is a timing problem.

Classify the failure before you touch a number.

When lowering a timer helps, and when it does not

Lower the retry ceiling when the dominant cost is waiting after a short, frequent outage, such as a laptop moving between access points. Leave it alone when failures are long or rare, because aggressive retrying adds load at the exact moment the concentrator is least able to answer. In both cases, change one parameter, record it, and measure the next recovery instead of assuming it improved.

A very low timeout copied into every profile is the usual end state of tuning without measurement.

Check readiness before you blame the client

The client often cannot see that the network is usable until something tries. A captive portal, a DHCP renewal or a route change can leave it waiting on a schedule set before any of that happened. Watch the operating system's network state change and the client's next attempt on the same clock, and you will see whose wait it is. The quick version is to note the timestamp of the network-ready event and the timestamp of the first attempt after it.

Confirm that direct traffic is still blocked during the wait as well, because a faster reconnect that leaks traffic is not an improvement.

What to record

Write down which timer changed, from what value to what value, and what recovery looked like afterwards. Note the client version too, because defaults move between releases and an undocumented very low timeout will confuse the next person who reads the profile.

That record turns the next software upgrade into a comparison rather than an experiment.