Locked Out by a VPN Retry Loop: Stop the Client First

At 02:40 the account locks and nobody is at the keyboard. A client on a shelf keeps presenting the password it saved last month, the gateway keeps rejecting it, and the counter behind the lockout climbs without a human involved. That is a retry loop rather than an attack, and it has to be stopped before the account can be recovered.

Treat it as two problems in a fixed order. Stop the sender first, then restore access, because doing it the other way round restarts the loop within minutes.

Find Which Process Is Submitting the Failures

Start from the timestamps in the identity system and line them up against each client that holds the account. A managed profile, an unattended service, a phone in a drawer and a spare laptop with old credentials can all authenticate as the same person. The one that fails every few seconds is the loop, and the one that fails once a day is usually a human who forgot. Both feed the same counter, which is the trap.

Distinguish a rejection from an unreachable gateway while you look. A timeout, a name resolution failure or a closed port does not normally increment a failure counter, while a completed authentication exchange that returns a bad-credential result does. Mixing the two produces the wrong fix, because one needs the client stopped and the other needs the path repaired.

Three Conditions That Decide the Response

Three facts narrow this to one answer. First, whether the record shows an explicit rejection or a transport failure. Second, whether the identity is shared across devices or services. Third, whether the retrying client is one you administer or one somebody else controls.

An explicit rejection from a single client you control means stop that client, unlock through the approved route and make one deliberate login. A shared identity pushes the answer toward provisioning rather than unlocking, since the loop will resume the moment the other device reconnects. Transport failures point at the network layer, where account protection is not the issue at all.

None of those branches involves weakening the protection. Lockout thresholds and rate limits exist because the same signal that annoys you during an outage is the signal that slows a password-guessing attempt.

Stop the Sender Before You Unlock

Stop the unit or connection that keeps authenticating, and stop it in a way that survives a reboot. Pausing the client is not enough when its service is set to start automatically at boot.

# which unit is presenting the credential?
journalctl -u openvpn-client@home --since '20 min ago' | grep -i 'auth\|error'

# stop it, and keep it stopped across reboots
sudo systemctl stop openvpn-client@home
sudo systemctl disable openvpn-client@home
systemctl is-active openvpn-client@home

Wait a few minutes and confirm the failure count stops moving. That pause is the proof you found the right source. If failures continue, the loop is coming from somewhere else and the unlocking step would be wasted.

Only then use the operator's documented unlock or recovery process, and follow it with exactly one controlled login from the device you intend to keep. Exact thresholds, cool-down periods and recovery wording are service-specific, so read them instead of guessing at a number.

Remove the Cause So It Does Not Return

Update the saved credential where it is owned: the operating system keyring, the client profile, or the service account configuration. Clearing it from one place while another keeps a copy is how the loop returns a week later, usually when a laptop that was offline comes back and replays its cached value.

Give automation its own identity. A separately provisioned account with its own credential and its own limits keeps a machine failure from locking a person out of email, and it makes the failure attributable in the logs. Add a backoff to the client so a rejected credential stops the retries instead of repeating them, and alarm on repeated authentication failures so the next loop is noticed in minutes rather than at 02:40.

When the report goes to support, keep the account identifier, the timestamps and the client name. Passwords and recovery material never belong in that record.