MFA Service Down: Decide VPN Admission Before It Fails

VPN admission stops, and the alert says the second-factor service is unreachable. Whether anyone can still connect is a policy question that was supposed to be answered before the outage, not during it. An unavailable verifier is not evidence that a factor passed, and a rejected challenge is not the same event as an unreachable one. The runbook below turns that distinction into a written rule you can test.

Step 1: name the three outcomes separately

Write down three states and refuse to collapse them: primary authentication failed, the second-factor challenge was denied or timed out, and the MFA service never answered. Each has a different owner, a different log line and a different correct response. A single generic timeout message hides which one you are in, and that ambiguity is what turns an outage into an argument. Name the states in the runbook before you need them.

A denial means the verifier answered and said no, which is a policy outcome rather than an availability problem. An expired attempt means the challenge existed and nobody completed it in time. An unreachable service means the question was never answered at all. Only the third is an outage.

Step 2: read the failure mode the proxy actually uses

Find the setting that governs behaviour when the service cannot be contacted, and read it from the running configuration rather than from a template. In Duo's RADIUS proxy, the documented failmode values are safe and secure, with safe permitting an attempt only when primary authentication succeeds and secure rejecting the attempt in that condition.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

The name safe describes an availability choice, not a guarantee that every admitted session had a fresh second factor. That sentence belongs in the risk register, because it is the exact trade the setting makes. Do not generalise the value to another provider, another integration or a different proxy mode; read that product's documentation for its own equivalent. A configuration copied from a vendor example without this understanding is a surprise waiting for the next outage.

Stop if nobody can say which mode is active. The rest of the runbook depends on that answer.

Step 3: make retries match the flow

Align the gateway's timeout and retry behaviour with the authentication flow it is driving. Uncoordinated retries create multiple prompts, confuse attempt matching and leave the log unable to say which result belongs to which login. A very long timeout is not an availability design; it is a longer wait for the same answer.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

The proxy's own request timeout is a separate limit: an authentication request that is issued and never completed is rejected, and that rejection is not an outage to fall back from. Treat a denial, an unfinished challenge and an unreachable service as three different inputs to your decision table. Then make the table explicit: which state admits, which state holds, and which state escalates to a human.

If two components both retry, fix the retry ownership first. Duplicate prompts are a symptom of two owners, not of a slow service.

Step 4: govern emergency access separately

If emergency access is required, give it its own scope, identity, authorization and audit trail. Quietly disabling MFA for all users is not an emergency procedure; it is a permanent weakening with an incident attached. The security owner approves the admission rule, the visibility and the escalation path in advance.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Test the whole matrix in a non-production environment: primary failure, deliberate rejection, challenge expiry and service unavailability. For each one, record the admission result and the reason that was logged. Do not create a production outage to discover the configured behaviour, and do not test the emergency path for the first time during the incident it was written for. A recovery procedure that has never run is a document, not a control.

The runbook ends when the three states are named, the failure mode is read from the running system, retries have one owner, and emergency access has its own approval and review. Predictable enforcement plus a known recovery path is the outcome worth documenting.