Why a VPN Reconnect Asks for Credentials Again
A saved password and a reusable token expire on different schedules. Read which material the reconnect asked for before changing anything on the client.
A tunnel that worked for hours asks for a password the moment the laptop wakes, and nothing in the configuration changed. What did change is the state of the credential the reconnect tried to reuse. Three kinds of material govern that, and only one of them survives an arbitrary gap.
Read which one the client asked for, because the three expire on different clocks and fail with different messages.
Three kinds of reusable material
A cached password is a secret held by the client, and it stays valid until the account changes it. A session token is issued by the server after a successful login, carries its own lifetime and can be revoked at any moment. A TLS session ticket or an IKE security association is protocol state, cheap to resume and completely independent of your password. Each is issued by a different component, and each expires on its own terms.
The first survives a reboot, the second usually survives a suspend, and the third may not survive a network change at all. Confusing them produces the wrong fix, such as resetting a password that was never rejected.
The prompt itself is the diagnostic. A browser window or a second-factor code means the server demanded interactive authentication, while a silent failure with no prompt means the client never got far enough to be asked.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Rekeying is not reauthentication
A rekey replaces keys while keeping the authenticated identity, which is why it happens silently every so often on a healthy tunnel. Reauthentication repeats the identity check itself, and that is the event that needs you. IKEv2 separates the two explicitly, and a peer can require a full reauthentication at a configured interval regardless of how many rekeys happened in between. The two events look identical from the outside until you read which one the log names.
OpenVPN behaves the same way in its own vocabulary: a renegotiation interval refreshes the data channel, and an authentication token can be handed back to the client to avoid a full login on the next connection. That token has a lifetime, and the server decides whether to accept it again.
So a reconnect after eight hours can fail where a reconnect after eight minutes succeeded, without any configuration change on either side. That is the whole explanation for a prompt that appears only after lunch.
When the client cannot complete the new challenge
A policy that requires a browser step will fail on a client that has no way to show one. Headless servers, startup scripts and legacy profiles built for password-only authentication all hit that wall, and the failure often appears as a generic timeout rather than an authentication error.
Device and network transitions can also fall inside a policy evaluation window, so a roam from Wi-Fi to a hotspot coincides with a check that would have happened anyway. The coincidence makes the network look guilty when the timer is the cause.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
The first line shows renegotiation and authentication events in the client's own log, and the second shows the security associations a strongSwan peer currently holds. Compare the timestamps with the moment the prompt appeared; a match confirms the timer rather than the network.
What to report, and what not to switch off
If a manual login succeeds and automatic reuse consistently fails, say exactly that to the operator. It names the component: the reuse path, not the credential. Include the time of the failure, the account in use and the prompt type you saw.
Do not disable the second factor, skip certificate validation or paste credentials into a script to make the reconnect silent. Each removes the check that the policy exists to enforce, and each converts a login prompt into an incident.
Ask instead for the supported flow: a client that can complete the challenge, a token lifetime that matches the working day, or an approved non-interactive profile for the machine that cannot prompt. Those are all configuration decisions someone can approve, which a workaround is not.