FYI - Windows 11 - Always On VPN Certificate Issues - PEAP

VPN
1

I just wanted to share some info regarding an issue I was running into (and fixed) while testing Windows 11.

I have both Device Tunnels and User Tunnels set up. The Device Tunnels, which only support IKEv2, work no problem authenticating with their machine certs against the VPN server. The User Tunnels, however, were running into certificate issues, most commonly complaining about a policy mismatch. Often an 853 error on the client, event IDs 20255 and 20271 on the VPN server, and a Reason Code 16 “Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect” on the NPS Server.

For me, it was a CAPITALIZATION issue in the subject name of the NPS Server’s certificate. Essentially, the PEAP settings of the VPN profile were specifying npsserverhostname.domain.com (NOTE: there are 2 of these entries in your profile), but the subject name of the actual certificate on the NPS server was NPSSERVERHOSTNAME.domain.com

After manually testing this by adjusting my PEAP settings on a test machine to match the UPPERCASE that existed in the NPS cert’s subject, I decided to leave the profile alone and instead adjust / fix the UPPERCASE subject name for the cert.

To do this:

-I edited the dNSHostName attribute of the NPS server’s computer object in Active Directory. Changed that from NPSSERVERHOSTNAME.domain.com to npsserverhostname.domain.com.

-Then I went to my CA>Manage Certificate Templates>right-clicked on the NPS server certificate template>”Reenroll All Certificate Holders.

-Back on the NPS server, from an administrative command prompt forced the reenroll by entering “certutil -pulse” and verified the new certificate now had the lowercase version of npsserverhostname.domain.com.

With the PEAP settings for the server name in section of my profile XML matching case sensitively with the subject name of the NPS server’s certificate, everything works a charm.

This was never an issue prior to Windows 11. I’ve yet to see anything about this in all my googling over the past month or so, so I hope this can help someone else. I’m sure I won’t be the only one who has some mismatching on their case sensitivity here.

​

There’s also a little bit of discussion on this over on Richard Hicks’ site as I first inquired with him when my troubleshooting was coming up short.

Troubleshooting Always On VPN Error 853 | Richard M. Hicks Consulting, Inc. (richardhicks.com)

​

Hopefully this can help some others

2

DNS names should not be case sensitive, hope they fix that.

3

I don’t think there’s a special case here, and it’s just a bug. Someone is strcmp() the string without normalizing it. This implies there’s some new code in that path, which is interesting.

Device Tunnel and Device Tunnel Only are a very interesting option, but Microsoft screwed up as usual by gating them behind Enterprise licensing. You see, Device Tunnel is really only intended by Microsoft to be able to contact the MSAD so that the User Tunnel can come up. And Microsoft assumes, and greatly desires, that any enterprise running MSAD will be using entirely Enterprise licensing on all nodes. From their perspective, this all makes sense – of course you’re sending millions of dollars to Microsoft every quarter for renewals, everyone does that, right?

DirectAccess had the Enterprise licensing fault, but it was also a bit too clever for mainstream customers to understand it, it officially required only Windows Server for tunnel termination which nobody wants to do anymore, and by using NAT64+DNS64 it didn’t work with legacy IPv4-only applications.

4

I have certificate issues in Windows 11 with our Radius setup also with root certificate not trusted errors. I wonder if the issue there is the same.

5

To this day, there still seem to be issues with Intune VPN User Tunnel’s.

The VPN profile is working on all our Windows 10 clients and Intune register the configuration as “Success”.
Windows 11 Clients get the profile and VPN Connection appear and connects just as expected - UNTIL the user either manually starts a Sync from the Company Portal, or the device automatically check in with Intune - then the VPN Profile gets removed and re-added, and now an error in Intune appears: “Windows10VpnConfiguration - Status: Error - Error code: -2016281112 - 0x87d1fde8”

This appear to “Just” be a generic remediation error, and from what I can gather it’s refering to an XML mismatch.
Intune expects the EAP-XML to return in a specific way, but after being applied the return XML does not match the configuration Intune-expects. Which means on the next sync/check in with intune - the Profile will be re-applied, which causes outage for the users.

6

Indeed. Not in Windows.

7

MS is aware of the issue, but haven’t been very vocal about fixing it since the patch in February - what is interesting though - I have a different tenant with a completely identitical User VPN tunnel - that deploys to those devices with NO issues at all - it’s so absurd.