VPN Login Stalls After a RADIUS Access-Challenge

Your password is right, the VPN login fails anyway, and the RADIUS server may have done exactly what it was told. The gateway probably received an Access-Challenge, showed nothing useful, and then timed out or treated that answer as a rejection. From the client side it looks like bad credentials or a broken tunnel. The cause usually sits in the middle of a conversation nobody captured.

One login, two RADIUS exchanges

When the backend wants a second factor, it does not answer the first request with accept or reject. It answers with code 11 and waits for the user's next response, which the gateway has to send back in a follow-up request. That follow-up belongs to the same authentication conversation, not to a fresh login attempt.

In a working setup the user sees a second prompt: password first, then a one-time code, or a single combined prompt if the operator documents one. In a broken setup the second prompt never appears and the login simply fails.

That is the symptom to chase, and it is easy to confirm from the client side alone: if the VPN client asks for exactly one secret and then rejects a password you know is valid, the exchange probably ended at the challenge.

What the challenge actually carries

The RADIUS specification describes code 11 in section 4.4 and allows two attributes that matter here. Reply-Message holds text meant for the user, and State holds an opaque value the server wants echoed back. The NAS is not supposed to interpret State, only to return it unchanged.

The follow-up request uses a new Identifier and a new Request Authenticator, and it must carry the same State value plus the user's response. The server matches it to the pending challenge through that State, which is why a gateway that regenerates or drops the attribute cannot complete the ceremony. The response authenticator on each reply also has to validate, or the NAS should discard the packet.

Section 4.4 adds the detail that explains most silent failures: a NAS that cannot support challenges treats Access-Challenge as a rejection. If your gateway's VPN service predates or omits that support, the backend's request for a second factor becomes an immediate "authentication failed" with no prompt at all.

Where the chained request gets lost

The first suspect is the prompt path rather than the credential. A portal that renders an OTP field for web logins does not automatically do the same for the VPN service, and some gateways only pass a challenge to clients that advertise the capability. Test the same account on both entry points; if the portal works and the VPN does not, you are looking at the handoff, not the token.

Input format is the second suspect. Concatenating password and code without the vendor's documented separator, or letting a saved credential replay an old code, fails in a way that looks identical to a wrong password. Use the operator's documented separate prompt or combined format, and never improvise a delimiter.

Release-specific defects do exist, but a list of fixed versions from years ago is not a diagnosis for today's deployment. Read the release notes for the software you actually run, and keep the observed exchange stage as your evidence.

Trace a single attempt end to end

Reproduce once, with server-side debugging on, and keep every other session out of the capture window:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

In the output, look for the shape of the conversation rather than a single line. A first Access-Request with Identifier 3, an Access-Challenge carrying State, then a second Access-Request with Identifier 4 that repeats that State and includes the user's response. If the second request is missing, the gateway never followed up. If it arrives without State, the server cannot match it to the pending challenge and will usually reject.

Redact credentials, tokens and unnecessary identity data when you share the trace, and correlate events from the one attempt instead of mixing retries from several browser tabs. Timestamps are your friend here; a challenge that arrives after the client gave up looks like a rejection to the user and like a slow reply in the log.

The finished state you want is a completed, authorized conversation followed by the intended service access. A response arriving from the RADIUS server proves much less than that.