VPN Client Connection Failures on Windows 11 Since This Morning — Authentication Policy Error

Question

VPN Client Connection Failures on Windows 11 Since This Morning — Authentication Policy Error

Ian Cox 50

Problem description

I am experiencing an issue where all my Windows 11 Point-to-Site VPN clients using IKEv2 and certificate authentication cannot connect to the Azure VPN Gateway since this morning. The error message indicates a policy mismatch during authentication: "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." I need assistance troubleshooting this connection failure.

Environment

Azure VPN Gateway Point-to-Site configuration, Tunnel type: IKEv2, Authentication: Certificate (EAP-TLS), Client OS: Windows 11, Gateway in default active-standby configuration across two instances.

What I've already tried

Tried new certificates, downloading new clients. resetting vpn

Current status

Currently, I am seeking guidance on how to diagnose and resolve the authentication policy mismatch preventing my VPN clients from connecting.

Richard B 0 Reputation points

2026-09-11T16:55:10.7+00:00
Hello Ian

Did you manage to resolve this issue? We've been faced with exactly the same issue since start of 10th September. We certainly hadn't changed anything on the Gateway config etc. - was working fine for a long time before this.

After a lot of investigation (we lost 2 days on this!) , we ended up creating a new VPN Gateway and deploying a new VPN config as a result. This worked.

Comparing the JSON config of the previous GW with the new one:

Public IP address setting - not really mentioned in the old one, is explicit in the new one

SKU: Generation1 changed to Generation2

Our suspicion is that something went wrong during VPN Gateway migration (this seemed to have been done automatically). We were on a Basic SKU (and still are). We had completed the Remove the Basic SKU public IP address reference back in April.

Hope this helps in some way.

Richard
Ian Cox 50 Reputation points

2026-09-14T07:21:52.2466667+00:00

We also ended up creating 2 new gateway and they worked. We just couldn't wait for MS to respond (waited 24 hrs - I didn't raise as top priority as we had work arounds but anyway I was disappointed with lack of timely response). One of the old gateways was basic the other was VpnGw1AZ so I don't think it is sku related. We had completed the public ip address migration ages ago.

I am certain MS deployed something that broke it, the fact the same thing happened to you around same time would support that.

Answer accepted by question author

0 additional answers

Your answer

Richard B 0 Reputation points

2026-09-11T16:55:10.7+00:00

Hello Ian

Did you manage to resolve this issue? We've been faced with exactly the same issue since start of 10th September. We certainly hadn't changed anything on the Gateway config etc. - was working fine for a long time before this.

After a lot of investigation (we lost 2 days on this!) , we ended up creating a new VPN Gateway and deploying a new VPN config as a result. This worked.

Comparing the JSON config of the previous GW with the new one:

Public IP address setting - not really mentioned in the old one, is explicit in the new one

SKU: Generation1 changed to Generation2

Our suspicion is that something went wrong during VPN Gateway migration (this seemed to have been done automatically). We were on a Basic SKU (and still are). We had completed the Remove the Basic SKU public IP address reference back in April.

Hope this helps in some way.

Richard
Ian Cox 50 Reputation points

2026-09-14T07:21:52.2466667+00:00

We also ended up creating 2 new gateway and they worked. We just couldn't wait for MS to respond (waited 24 hrs - I didn't raise as top priority as we had work arounds but anyway I was disappointed with lack of timely response). One of the old gateways was basic the other was VpnGw1AZ so I don't think it is sku related. We had completed the public ip address migration ages ago.

I am certain MS deployed something that broke it, the fact the same thing happened to you around same time would support that.

Answer 1

Hello @Ian Cox

Based on the symptoms and Richard's additional report, be cautious about treating this as a standard Windows 11 EAP-TLS/certificate configuration issue.

Your environment was previously working; all Windows 11 P2S clients started failing at roughly the same time, and replacing certificates/re-downloading the VPN client configuration didn't resolve it. Another user in this thread has now reported essentially the same behavior beginning around September 10, with no intentional VPN Gateway configuration changes. Recreating the VPN Gateway resolved the problem in their environment.

That pattern suggests the generic Windows error: "The connection was prevented because of a policy configured on your RAS/VPN server..." may be misleading here. It doesn't necessarily prove the client authentication policy itself is misconfigured.

First, check the Azure VPN Gateway resource and migration state, especially if this gateway was using the Basic SKU or a legacy Basic public IP configuration.

Microsoft has been migrating Basic SKU VPN Gateways from Basic SKU public IP addresses because it is retiring Basic SKU public IPs. Microsoft documents a specific migration process for affected VPN Gateways.

Since Richard noticed differences between the old and newly created gateway configuration and suspects migration activity, I would check the Activity Log around the time the failures began for any gateway/public-IP operations that weren't initiated by your administrators.

Also, collect the Windows VPN logs rather than relying only on the GUI error:

Event Viewer → Applications and Services Logs → Microsoft → Windows → RasClient → Operational

and:

Event Viewer → Applications and Services Logs → Microsoft → Windows → CAPI2 → Operational

RasClient can help identify where the VPN connection fails, while CAPI2 helps determine whether certificate-chain validation is failing.

On one affected client, also verify that:

the client certificate still has a private key;
the certificate contains the Client Authentication EKU;
the certificate chains to the root certificate configured on the P2S gateway;
the certificate isn't expired or revoked;
the downloaded VPN profile still specifies IKEv2;
the expected root certificate remains under the gateway's Point-to-site configuration.

However, because you've already generated new certificates and downloaded new VPN client configurations, don't keep rotating certificates unless the CAPI2/RasClient logs actually indicate a certificate-validation failure.

One particularly useful isolation test would be to create a temporary second VPN Gateway/P2S configuration using the same certificate hierarchy. If the same Windows 11 client authenticates successfully against the new gateway, that strongly isolates the issue to the existing gateway rather than Windows or the client certificate. Richard's result in this thread already points in that direction.

Also, avoid deleting/recreating the production gateway as the first troubleshooting step. Replacing a VPN Gateway can change public IP/configuration dependencies and cause downtime.

If the logs don't identify a client certificate issue, open an Azure support case and ask the VPN Gateway engineering team to check the backend state and recent migration history for both gateway instances. Since the gateway is active-standby, Microsoft can also determine whether the authentication failures correlate with one or both instances.

Provide them with:

VPN Gateway resource ID and SKU
Gateway generation
Public IP SKU/configuration
UTC time when the problem started
RasClient event IDs/errors
Confirmation that all clients began failing simultaneously
Confirmation that new certificates and newly downloaded VPN profiles also fail
Whether the gateway recently underwent a Basic Public IP/VPN Gateway migration

Given that a second customer has now reported the same sudden behavior and successfully recovered by creating a new gateway, I think a gateway migration/backend-state investigation is warranted before making further client-side changes.

References:

Configure P2S certificate authentication

Troubleshoot Azure P2S connections

Basic Public IP migration for VPN Gateway

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Ian Cox 50 Reputation points

2026-09-14T07:24:41.13+00:00

We definitely had new versions of the gateway installed by MS early morning before we found it broken that morning. I agree an investigation is warranted. We too ended up installing new gateways as we couldn't wait any longer. So the old gateways are now deleted, it wll be hard to investigate further, but we also didn't really want to be paying for a broken gateway. In the logs it was a version change to 26.6.100.18. from 26.3.100.20 that occurred.
Richard B 0 Reputation points

2026-09-14T10:14:10.1733333+00:00

Hi @Allan Solomon Mejia

Thanks for the useful pointers on this. In answer to some of these:

Activity Log - no entries for gateway/public-IP operations around this time

Change analysis - Virtual network gateway - Resource Updated - 08/09/2026 and 7th. No further details. But it was working fine on 9th anyway.

Windows VPN logs - no entries in either of those logs, but a wider search showed mostly RAS error 628, some connections 812.

We did create a temporary second VPN Gateway/P2S configuration using the same certificate hierarchy on Friday - this connected fine.

Unfortunately we cannot open an Azure support case as we no longer have an Azure Support plan (had several bad experiences).

Same as Ian, we couldn't wait any longer to get this working again, so decided to recreate the gateway. So far, so good.

Thanks for your help.

Richard
Allan Solomon Mejia 10,145 Reputation points

2026-09-14T14:48:46.22+00:00

Hi @Ian Cox @Richard B

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. Thank you.