RouterOS OpenVPN y NPS: configura user-auth-method, no auth

RouterOS puede llegar a NPS con un inicio de sesión OpenVPN y aun así ser rechazado, y la causa habitual son dos ajustes cuyos nombres suenan ambos a autenticación. Uno elige un resumen criptográfico para el túnel; el otro decide cómo se presentan las credenciales del usuario a RADIUS. Cambiar el resumen nunca convertirá una solicitud PAP en MS-CHAPv2, por muchas veces que se reinicie el servicio. La lista de comprobación siguiente separa ambos y luego sigue un único inicio de sesión fallido por la política de NPS que lo juzgó.

Paso 1: lee ambos ajustes antes de cambiar cualquiera

Imprime la configuración efectiva del servidor OpenVPN en el router que termina el túnel, no desde una copia de seguridad ni desde un mensaje de foro copiado. Los dos campos que te importan suelen estar en el mismo menú y se leen como si fueran alternativas. No lo son: uno trata del canal de datos, el otro del intercambio de credenciales.

/interface ovpn-server server print
/interface ovpn-server server export

El campo auth enumera resúmenes como sha1 y sha256 y controla el HMAC que autentica los paquetes del túnel. El campo user-auth-method elige pap o mschap2 y decide cómo presenta el router las credenciales del usuario a RADIUS. Un cambio de resumen no puede alterar el segundo comportamiento, y por eso el mismo rechazo sobrevive a cada ajuste del primero.

Detente aquí si tu versión no expone user-auth-method en absoluto. Las compilaciones antiguas de RouterOS pueden no ofrecerlo en el servidor OpenVPN, y la solución pertenece a una versión que puedas soportar, no a un comando copiado de una más nueva.

Paso 2: encuentra la política que realmente rechazó el inicio de sesión

En el lado de NPS, una solicitud de conexión se evalúa contra las políticas de red, y el método de autenticación indicado en la política coincidente debe ser uno que el cliente haya ofrecido realmente. Correlaciona un inicio de sesión fallido por hora y usuario en lugar de leer un recuento resumido. El registro de seguridad anota las solicitudes concedidas y denegadas con un código de motivo, lo que te dice mucho más que la línea genérica de fallo del router.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Lee tres cosas en el evento: el nombre de la política coincidente, el método de autenticación y el código de motivo. Una política que exige MS-CHAPv2 rechaza una solicitud PAP incluso cuando la contraseña es correcta, y una política que exige una cuenta de dominio rechaza una local. La entrada de cliente RADIUS también debe coincidir con la dirección de origen del router, o la solicitud se descarta antes de consultar cualquier política. Nada de eso aparece en el registro de OpenVPN.

Detente aquí si la solicitud nunca llega a NPS. Eso es un problema de secreto compartido, dirección de cliente o UDP 1812, y cambiar los métodos de autenticación no lo arreglará.

Paso 3: cambia un método, en ambos lados

Si el diseño aprobado es MS-CHAPv2, configúralo en el router y confirma que la política coincidente lo acepta. Cambia un lado, vuelve a probar y luego cambia el otro; cambiar ambos a la vez te deja sin poder decir cuál importaba.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

No habilites todos los métodos más débiles en NPS para que el error desaparezca. El backend debe tener material que el método elegido pueda verificar: MS-CHAPv2 necesita acceso a la contraseña o al dominio, y una política no puede inventar ese material. Ampliar la política también amplía lo que un atacante puede intentar contra la misma cuenta. Anota el método, el nombre de la política y la referencia del cambio juntos, para que la siguiente persona herede una decisión y no una suposición.

Deja la validación del certificado del túnel exactamente como estaba. Un método de credenciales no sustituye la identidad del servidor, y bajar las comprobaciones TLS para que pase una prueba cambia un problema por otro peor.

Paso 4: prueba tres inicios de sesión y un permiso

Prueba un usuario permitido, una contraseña incorrecta y un usuario excluido, cada uno en una sesión nueva. El primero demuestra la ruta, el segundo demuestra que la comprobación de credenciales es real y el tercero demuestra que la política sigue excluyendo a quien debe. Una sesión en caché puede ocultar los tres, así que desconéctate entre intentos.

/log print where topics~"ovpn"
/radius monitor 0

El éxito de la autenticación no es el final de la lista. Comprueba la dirección que recibió el cliente y los recursos que esa dirección puede alcanzar, porque un usuario puede autenticarse correctamente y acabar igualmente en el grupo incorrecto. Si la dirección asignada es incorrecta, el problema está en el perfil o en los atributos de respuesta RADIUS, no en el método. Confirma ambas cosas antes de cerrar el ticket.

La lista está terminada cuando el ajuste del router y la política de NPS nombran el mismo método, un usuario permitido se conecta con una sesión nueva, una contraseña incorrecta se rechaza, un usuario excluido sigue excluido y la dirección asignada coincide con el grupo previsto. Cualquier cosa menos deja el siguiente inicio de sesión al azar.