RouterOS OpenVPN and NPS: Set user-auth-method, Not auth

On RouterOS, auth picks the tunnel digest while user-auth-method decides how the RADIUS request is checked. Align the second with the NPS policy.

RouterOS can reach NPS with an OpenVPN login and still have it rejected, and the usual cause is two settings whose names both sound like authentication. One selects a cryptographic digest for the tunnel; the other decides how the user's credentials are presented to RADIUS. Changing the digest will never turn a PAP request into MS-CHAPv2, no matter how often the service restarts. The checklist below separates the two, then follows a single failed login through the NPS policy that judged it.

Step 1: read both settings before changing either

Print the effective OpenVPN server configuration on the router that terminates the tunnel, not from a backup or a copied forum post. The two fields you care about usually sit in the same menu and read as if they were alternatives. They are not: one is about the data channel, the other is about the credential exchange. Write both values down before you touch anything.

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

The auth field lists digests such as sha1 and sha256, and it controls the HMAC that authenticates tunnel packets. The user-auth-method field chooses pap or mschap2 and decides how the router presents the user's credentials to RADIUS. A digest change cannot alter the second behaviour, which is why the same rejection survives every tweak to the first.

Stop here if your release does not expose user-auth-method at all. Older RouterOS builds may not offer it on the OpenVPN server, and the fix belongs in a release you can support rather than in a command copied from a newer one.

Step 2: find the policy that actually rejected the login

On the NPS side, a connection request is evaluated against network policies, and the authentication method named in the matched policy has to be one the client actually offered. Correlate one failed login by time and user instead of reading a summary count. The security log records granted and denied requests with a reason code, which tells you far more than the router's generic failure line.

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

Read three things in the event: the matched policy name, the authentication method and the reason code. A policy that requires MS-CHAPv2 rejects a PAP request even when the password is correct, and a policy that requires a domain account rejects a local one. The RADIUS client entry must also match the router's source address, or the request is dropped before any policy is consulted. None of that appears in the OpenVPN log.

Stop here if the request never reaches NPS. That is a shared secret, client address or UDP 1812 problem, and changing authentication methods will not fix it.

Step 3: change one method, on both sides

If the approved design is MS-CHAPv2, set it on the router and confirm that the matching policy accepts it. Change one side, retest, then change the other; changing both at once leaves you unable to say which one mattered.

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

Do not enable every weaker method on NPS to make the error disappear. The backend has to hold material the chosen method can verify: MS-CHAPv2 needs access to the password or to the domain, and a policy cannot invent that material. Widening the policy also widens what an attacker may try against the same account. Record the method, the policy name and the change reference together, so the next person inherits a decision rather than a guess.

Keep the tunnel's certificate validation exactly as it was. A credential method is not a substitute for server identity, and lowering TLS checks to make a test pass trades one problem for a worse one.

Step 4: test three logins and one permission

Test a permitted user, a wrong password and an excluded user, each in a fresh session. The first proves the path, the second proves the credential check is real, and the third proves the policy still excludes who it should. A cached session can hide all three, so disconnect between attempts.

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

Authentication success is not the end of the checklist. Check the address the client received and the resources that address can reach, because a user can authenticate correctly and still land in the wrong pool. If the assigned address is wrong, the problem sits in the profile or the RADIUS reply attributes, not in the method. Confirm both before closing the ticket.

The checklist is done when the router setting and the NPS policy name the same method, one permitted user connects with a fresh session, one wrong password is rejected, one excluded user is still excluded, and the assigned address matches the intended pool. Anything less leaves the next login to chance.

Artiglyn mynjee