El inicio de sesión de la VPN se bloquea tras un Access-Challenge de RADIUS

La contraseña es correcta, el inicio de sesión de la VPN falla igualmente, y el servidor RADIUS puede haber hecho exactamente lo que se le ordenó. La puerta de enlace probablemente recibió un Access-Challenge, no mostró nada útil y luego expiró o trató esa respuesta como un rechazo. Desde el lado del cliente parece una credencial incorrecta o un túnel roto. La causa suele estar en medio de una conversación que nadie capturó.

Un inicio de sesión, dos intercambios RADIUS

Cuando el backend quiere un segundo factor, no responde a la primera petición con aceptación o rechazo. Responde con el código 11 y espera la siguiente respuesta del usuario, que la puerta de enlace debe enviar en una petición de seguimiento. Esa petición de seguimiento pertenece a la misma conversación de autenticación, no a un intento de inicio de sesión nuevo.

En una configuración que funciona, el usuario ve un segundo aviso: primero la contraseña, luego un código de un solo uso, o un único aviso combinado si el operador documentó uno. En una configuración rota, el segundo aviso nunca aparece y el inicio de sesión simplemente falla.

Ese es el síntoma que hay que perseguir, y es fácil de confirmar solo desde el lado del cliente: si el cliente de la VPN pide exactamente un secreto y luego rechaza una contraseña que usted sabe válida, el intercambio probablemente terminó en el desafío.

Qué lleva realmente el desafío

La especificación de RADIUS describe el código 11 en la sección 4.4 y permite dos atributos que importan aquí. Reply-Message contiene texto dirigido al usuario, y State contiene un valor opaco que el servidor quiere recibir de vuelta. El NAS no debe interpretar State, solo devolverlo sin cambios.

La petición de seguimiento usa un Identifier nuevo y un Request Authenticator nuevo, y debe llevar el mismo valor de State más la respuesta del usuario. El servidor la empareja con el desafío pendiente mediante ese State, y por eso una puerta de enlace que regenera o descarta el atributo no puede completar la ceremonia. El response authenticator de cada respuesta también debe validar, o el NAS debería descartar el paquete.

La sección 4.4 añade el detalle que explica la mayoría de los fallos silenciosos: un NAS que no puede soportar desafíos trata Access-Challenge como un rechazo. Si el servicio de VPN de su puerta de enlace es anterior a ese soporte o lo omite, la petición del backend de un segundo factor se convierte en una «autenticación fallida» inmediata sin ningún aviso.

Dónde se pierde la petición encadenada

El primer sospechoso es la ruta del aviso, no la credencial. Un portal que muestra un campo OTP para los inicios de sesión web no lo hace automáticamente para el servicio de VPN, y algunas puertas de enlace solo pasan un desafío a los clientes que anuncian la capacidad. Pruebe la misma cuenta en ambos puntos de entrada; si el portal funciona y la VPN no, está mirando la entrega, no el token.

El formato de entrada es el segundo sospechoso. Concatenar contraseña y código sin el separador documentado por el proveedor, o dejar que una credencial guardada reproduzca un código antiguo, falla de una manera que parece idéntica a una contraseña incorrecta. Use el aviso separado o el formato combinado documentado por el operador, y nunca improvise un delimitador.

Los defectos específicos de versión existen, pero una lista de versiones corregidas de hace años no es un diagnóstico para el despliegue de hoy. Lea las notas de la versión del software que realmente ejecuta y conserve la etapa de intercambio observada como su evidencia.

Rastree un solo intento de principio a fin

Reproduzcalo una vez, con la depuración del servidor activada, y mantenga cualquier otra sesión fuera de la ventana de captura:

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

En la salida, busque la forma de la conversación más que una sola línea. Un primer Access-Request con Identifier 3, un Access-Challenge que lleva State, y luego un segundo Access-Request con Identifier 4 que repite ese State e incluye la respuesta del usuario. Si falta la segunda petición, la puerta de enlace nunca hizo el seguimiento. Si llega sin State, el servidor no puede emparejarla con el desafío pendiente y normalmente la rechazará.

Oculte credenciales, tokens y datos de identidad innecesarios cuando comparta la traza, y correlacione los eventos de un solo intento en lugar de mezclar reintentos de varias pestañas del navegador. Las marcas de tiempo son su amiga aquí; un desafío que llega después de que el cliente se rindió parece un rechazo para el usuario y una respuesta lenta en el registro.

El estado final que desea es una conversación completada y autorizada seguida del acceso previsto al servicio. Una respuesta que llega del servidor RADIUS demuestra mucho menos que eso.