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 nps.lab.richardhicks.net, using NPS.lab.richardhicks.net 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.
Recommendations
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
Ronald Oosterloo
/ September 23, 2021Yes it works fine. We found it after a lot of hours.
Thanks for your help with searching.
Some Guy
/ September 23, 2021Are 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 lab4richardhicks.net 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.
Richard M. Hicks
/ September 23, 2021No, 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.
Zack
/ September 24, 2021Wow, 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.
Richard M. Hicks
/ September 24, 2021Agreed. 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!
trulyvexed
/ October 6, 2021Hi 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?
Richard M. Hicks
/ October 6, 2021I’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!
Jo
/ October 12, 2021Hi 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?
Richard M. Hicks
/ October 13, 2021I’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!
mrman5917
/ October 13, 2021I’m also getting the same problem. I’ve entered a ticket but no movement yet. I did also submit a Feedback during the beta period. https://aka.ms/AAdtyuu
Ulf
/ October 14, 2021Yes this have been driving me crazy! Im having this exact problem also. Where do you find this event log ?
Sven
/ October 21, 2021Have you had any luck with Microsoft on this?
Andy
/ October 26, 2021https://docs.microsoft.com/en-us/mem/intune/configuration/vpn-settings-configure
For Windows 11 devices, there is an issue between the Windows 11 client with the Windows VPNv2 CSP that results in a device with one or more Intune VPN profiles losing its VPN connectivity when the device processes multiple changes to VPN profiles for the device at the same time. The connectivity is restored when the device checks-in with Intune a second time to process those VPN profile changes.
Changes that can cause loss of VPN functionality include:
Edits to a VPN profile that was previously processed by the Windows 11 device. This action deletes the original profile and is followed by application of the updated profile.
Two new VPN profiles apply to the device at the same time.
The removal of an active VPN profile at the same time a new VPN profile is assigned.
This issue doesn’t apply to:
A Windows 11 device when it receives a single Intune VPN profile, and the device doesn’t already have a VPN profile assigned.
Windows 11 devices that have a VPN profile assigned and are then assigned an additional VPN profile with no other profile changes.
When a Windows 10 device upgrades to Windows 11, so long as there are no changes to that device’s VPN profiles. However, after the upgrade to Windows 11, any changes to the devices VPN profiles or the addition of new VPN profiles will trigger the issue.
This issue and warning remain in effect until Windows updates the Windows 11 client to resolve this issue.
Richard M. Hicks
/ October 26, 2021Thanks for the insight, Andy!
Jo
/ February 9, 2022Our solution is, that we created a new configuration profile in Intune with the profile type “Custom”.
This profile is configured with the required OMA-URI and the ProfileXML.
This configuration also deletes the VPN Connection with every Intune Sync, but it is able to recreate the connection in the same sync cycle. So there is only a very short downtime of the VPN connection which is ok for us.
Another problem with this configuration is, that you need local administrator permissions to remove the profile. But we don’t need this very often.
hsxx
/ October 14, 2021Our W11 users are experiencing random connectivity problem “Couldn’t connect because we couldn’t find a certificate for single sign-on. Please contact your support person.” For some this repeats daily, for some others occasionally, for some never. None of our W10 users have reported this. Our AO VPN solution is only in a PoC phase so the user base is pretty limited though.
We have the conditional access setup with Azure certificates and that part is not the problem. The VPN configuration includes the separate SSO certificate which is our user certificate autoenrolled from our corporate AD CA and is also used for WiFi and dot1x authentication.
The certificates are in the validity period and if the users use some other connectivity to reissue it works but maybe only for a day or two after which another renewal fixes it for a while. The certificate validity period is several months anyway, so that is not the issue.
Fortunately or unfortunately I haven’t seen this issue myself so that I could troubleshoot it any deeper.
Tomy
/ October 25, 2021There are only half the amount of certificates in a fresh install of windows 11 vs windows 10 OS, the absence of these certificates are causing similar issues I.e. in my case it’s vpn error 13801… installing certs from windows 10 helps!! 😮
Richard M. Hicks
/ October 26, 2021🙂
Humber
/ February 7, 2022is there no fix to this issue: MDM ConfigurationManager: Command failure status.
Richard M. Hicks
/ February 7, 2022There are some other things that are broken with WMI-to-CSP bridge in Windows 11 that could be affecting this, but I’m not certain.
Eric Rose
/ February 9, 2022MY HERO! We had this EXACT issue. Mismatched case on the PEAP server name and the SAN on the certificate on the NPS server. Thank you for finding this. This page will get a lot of hits as enterprises start rolling out Windows 11.
Richard M. Hicks
/ February 9, 2022😁