Always On VPN Error 853 on Windows 11

Recently I did some validation testing with Always On VPN on Windows 11, and I’m happy to report that everything seems to work without issue. However, a few readers have reported 853 errors when establishing an Always On VPN connection after upgrading to Windows 11.

Can’t Connect

After upgrading to Windows 11, an Always On VPN connection may fail with the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure the certificate used for authentication is valid.”

Error 853

In addition, the Application event log records an event ID 20227 from the RasClient source that includes the following message.

“The user <username> dialed a connection name <connection name> which has failed. The error code returned on failure is 853.”

Server Identity

This error will occur when using Protected Extensible Authentication Protocol (PEAP) authentication. Specifically, it can happen when the option to verify NPS server validity by its certificate is selected, and an explicit list of NPS servers is defined, as shown here.

Case Sensitive

In this specific scenario, Windows 11 now appears to be case-sensitive when it compares the NPS server name entered in the NPS configuration to the Subject Name on the certificate returned by the server. For example, if the Subject Name (or Subject Alternative Name, if present) entry on the NPS server certificate is, using will not match and return an 853 error.

Windows 11

Case matching when validating the NPS server certificate is a change in behavior from Windows 10. Before Windows 11, this comparison was case-insensitive, and any combination of case would match if the entire hostname matched. Going forward, it appears Microsoft has also decided to require case matching to validate the server certificate.


Administrators should look carefully at the server certificate issued to the NPS server and ensure their client configuration accurately reflects the hostname in a case-sensitive manner to ensure a smooth migration from Windows 10 to Windows 11.

Additional Information

Troubleshooting Windows 10 Always On VPN Error 853

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing

Leave a comment


  1. Ronald Oosterloo

     /  September 23, 2021

    Yes it works fine. We found it after a lot of hours.
    Thanks for your help with searching.

  2. Some Guy

     /  September 23, 2021

    Are you sure it’s only case-comparison behaviour that’s changed and not something even further with the regular expression behaviour? Variations of that dialog box are also used for PEAP for 802.1X wired/wireless authentication, as well as for group policy editor to edit policies for 802.1X. Since about 2008/Vista (IIRC) the behaviour of how the regular expressions get evaluated has been inconsistent so I am not surprised you discovered some more unexplainable behaviour with it. IIRC it sometimes gets evaluated as just a plain string of a hostname and it sometimes gets evaluated as a proper regular expression as shown in the examples given in the dialog box. E.g. depending on client OS, OS used to edit the GPO, etc.

    It also opens up careless admins (who don’t read the examples when typing into a text box!) to an implementation vulnerability: in regular expressions, “dot” is a wildcard character not a label separator, so e.g. right now I could go out and purchase the domain name and create certificates that your regular expression would happily match (except in the situations where Windows decides to not actually evaluate it as regex).

    Anyway, I wonder if the change you noticed with case-comparison means Microsoft has finally sorted out their act with this dialog box and implemented consistent actual regex evaluation or if it means they are still continuing to cluelessly implement further inconsistent behaviour.

    • No, I am not. What I’m sure of is that the behavior changed, and my testing demonstrated clearly that the string had to match the case on the certificate. You’re right though, regex is supported for matching here, and perhaps Microsoft decided to finally implement it completely, which would include case matching.

  3. Wow, I can see this tripping up a lot of administrators unless there is a big communication campaign from Microsoft. They should also include in the error that certificate and server names are case sensitive, so the true cause is less ambiguous.

    • Agreed. Windows 11 is still pre-release, so it’s possible this could change. I can definitely see this breaking a lot of implementations in the field, resulting in a deluge of support calls for them. Time will tell!

  4. trulyvexed

     /  October 6, 2021

    Hi Richard, not entirely in the scope of your post but are you aware of any changes required for the profilexml under Windows 11?

    I’ve been deploying Device Tunnels using a ConnectWise control (SYSTEM context) via a script on Windows 10 without issue.

    On a fresh install of Windows 11 the exact same script fails to install with a “A general error occurred that is not covered by a more specific error code.” error.

    Even more irritating however is if I install the device tunnel on Windows 10 and in-place upgrade to Windows 11, it still works fine!

    Don’t suppose you’ve seen this behaviour anywhere?

    • I’m very early in my testing, but I can confirm I’m seeing similar behavior. I deploy the device tunnel and user tunnel in my lab using Active Directory group policy startup scripts, which run in the system context. The device tunnel installs fine, but the user tunnel gets borked and doesn’t work. Oddly, if I delete the profile and let it install again it works the second time.

      I’ll probably post something on my findings here soon. Stay tuned!

  5. Jo

     /  October 12, 2021

    Hi Richard,
    I’m testing Windows 11 with AoVPN (installed by Intune). My problem is that the first Intune sync removes the AoVPN profile with this event log error:

    “MDM ConfigurationManager: Command failure status. Configuration Source ID: (XXXXXXXXXX), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (VPNv2), Command Type: (Add: from Replace or Add), CSP URI: (./User/Vendor/MSFT/VPNv2/vpn-profile), Result: (The specified quota list is internally inconsistent with its descriptor.).”

    With the next sync, the AoVPN profile gets installed again, but the next sync will again remove the profile until the fourth sync installs it again.
    And so on…
    Have you already heard something about that?

    With the next sync, the AoVPN profile is reinstalled, but the following sync removes it again until the fourth sync reinstalls it. This procedure is repeated throughout the day.

    Have you heard anything about it?

    • I’m hearing numerous reports of this. I’d suggest opening a support case with Microsoft so they are aware of the problem. Hopefully they get it sorted out soon!


Leave a Reply

%d bloggers like this: