Server 2022 - NPS and Always-On VPN Caution

[CHiLL]

Over Easter, I tested and in-place upgraded our production servers to Server 2022 (apart from our Always-On VPN server, which I attempted the upgrade on, but it would fail and revert the changes and go back to Server 2019). I had tested the VPN after the upgrades and it worked fine on the devices I tested with, with multiple accounts.

 

However, once we came back after the Easter break, I was slowly getting reports that the VPN wasn't working for some users. So after some investigating...I found an issue that baffled me. I had a user and their laptop which wasn't working on the VPN and I could replicate the issue every time. I also logged on as another user that I know can access the VPN and it also didn't work. As a test, I got another laptop and logged on as both users, using the same 4G hotspot to connect...and they worked on this laptop! The config is exactly the same, deployed the same way (Powershell and XML via SCCM) and there are no hardware requirements causing the issue. Since the VPN uses certificates to authenticate (with both users on both devices having ALL the correct certificates installed), I was completely baffled as to why they'd connect on one device, but not the other.

 

The client reported the following error while trying to establish the connection:

The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error. (Error 812) For customized troubleshooting information for this connection, click Help.

 

 

Checking the VPN server Event Viewer, the following pairs of errors were being logged:

CoId={1B4ED3EE-B5AA-FD8A-11EA-51DCBEF00605}: The following error occurred in the Point to Point Protocol module on port: VPN2-126, UserName: . The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

 

CoId={C0272FC7-23A0-E68F-4218-EC2ED5437F5F}: The user connected from but failed an authentication attempt due to the following reason: The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

 

I checked, double checked and tripple checked the VPN config, both on the VPN server and NPS server and they were correct when compared against the online installation guides and notes I made during deployment. After a couple of days of getting nowhere, I resorted to restoring the VPN server from a restore point prior to the upgrade. Alas, that didn't resolve the issue.

 

All the evidence was pointing to an issue with the NPS server, though I couldn't pinpoint exactly what. So I ended up restoring the NPS server, also to a point prior to the Server 2022 upgrade. Once it came back, I tested the VPN and it worked straight away.

 

I still don't understand why I could get the user to connect on one device and not the other, despite the exact same config, but so far this morning, it appears to be working as expected.

 

TLDR:

There seems to be some issues with NPS on Server 2022 that was causing authentication issues with some of our VPN connections. So maybe hold off that Server 2022 upgrade on an NPS server, if you had it planned.

[3s-gtech]

Eeeep. Our NPS is on a DC, which tend to get OS upgrades first. That can wait then!

 

Have the certificate requirements beefed up with the OS upgrade?

[CHiLL]

Eeeep. Our NPS is on a DC, which tend to get OS upgrades first. That can wait then!

 

Have the certificate requirements beefed up with the OS upgrade?

Same here, and our PDC at that too. Restoring it from VEEAM kind of messed up. VEEAM is meant to do a non-authorative restore by default, but after the restore, it wasn't able to communicate with our other DC and I was getting authentication issues. I had to resort to logging onto the problematic PDC, resetting the password for the other DC, then do a repadmin to update the PDC with info from the functional DC. It's been a day.

 

I have no idea regarding the certificates, because I can't wrap my head around why it was working on one device and not the other, despite being the same user, running the same OS (Win10 21H2 and with the same updates installed).

Edited April 28, 2022 by CHiLL

[3s-gtech]

It's going to be worth splitting NPS off - right PITA that'll be though.

 

Certs wise - thinking from a server perspective, perhaps there'll be a requirement for a stronger encryption level set on the AoVPN certificate template. The clients won't be the variable, it's the NPS server I'm wondering about.

[KK20]

ironically enough, might be easier to promote another DC - let that replicate from the "backup DC", demote the NPS/DC - offline if necessary.

[adamsund]

The timescales don't quite match up but I came across this today and it sounds like it could be related Windows 10, version 20H2 and Windows Server, version 20H2 | Microsoft Docs

[sallaberger]

Hi,

 

It looks like, that i have currently the same issue with NPS@Server 2022 in my environment. Have you ever solved it? Or do you have still Server 2019 for NPS?

[stgoodyeara]

Hi,

 

It looks like, that i have currently the same issue with NPS@Server 2022 in my environment. Have you ever solved it? Or do you have still Server 2019 for NPS?

 

+1 on this too. Posting for a follow.

 

"The following error occurred in the Point to Point Protocol module on port: VPN2-1, UserName: . The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error."

 

Just the one loan entry in the event logs.

[3s-gtech]

We have five years of extended lifecycle for 2019, I might just snuggle my AoVPN server into 2019 permanently (it'll be retired as a service before then I expect). My NPS is still on 2019 too though, so can't report on success with that bit.

[free780]

I managed to configure a dialup VPN a Fortigate which works with the Windows client. Generally been more reliable than RRAS. Win11 seems to do some random disconnect/reconnect. I think it’s due to Intune rather than the VPN.

[sallaberger]

Please check out this article: https://directaccess.richardhicks.com/2023/02/13/always-on-vpn-authentication-failed-reason-code-16/

[CHiLL]

Hi,

 

It looks like, that i have currently the same issue with NPS@Server 2022 in my environment. Have you ever solved it? Or do you have still Server 2019 for NPS?

Sorry, I initially missed this thread update. Unfortunately, I cannot remember that far back, though I do know around that time or sometime after, we migrated away from Microsoft's Always-On VPN to utilise the Sophos IPsec VPN that comes as part of our firewall package. It has been much more reliable than Microsoft's VPN solution.