VPN Gateway: Point-to-site VPN Connectivity Issue — All Users Cannot Connect

Question

VPN Gateway: Point-to-site VPN Connectivity Issue — All Users Cannot Connect

Matt Fox 0

Problem description

I am experiencing an issue where all users of my Point-to-Site VPN cannot connect. The expected behavior was that users should be able to establish a VPN connection and access resources through the tunnel, but currently, no users can connect.

Environment

Azure VPN Gateway with Point-to-Site enabled; Client platform: Windows; VPN client: Azure VPN Client; Tunnel type: IKEv2; Authentication: certificate-based; Region: not specified in case information.

What I've already tried

I have reviewed the initial impact scope and configuration details, including affected users, platform, VPN client, tunnel type, and authentication method. I also checked common troubleshooting steps such as refreshing the VPN profile, verifying certificate chains, and ensuring the root certificate is valid. Additionally, I confirmed that ports 500 and 4500 are open and tested connectivity from different networks. I attempted to update the VPN client, reinstall the package, and modify registry settings like DisableCertReqPayload, but these actions did not resolve the issue.

Current status

The problem persists with all users unable to connect since the reported time of 2026-10-21 14:00 UTC. I am seeking further assistance to identify the root cause and resolve the connectivity failure.

The error we get in event viewer is

CoId={81BA8069-619D-0009-0D3E-0B829D61DD01}: The user SYSTEM dialed a connection named vnet-unity4 which has failed. The error code returned on failure is 628.

0 comments

1 answer

Your answer

Answer 1

Hi Matt,

When every P2S user fails at the same moment, with nothing changed on your side, I'd look at the gateway's root certificate migration before anything on the clients.

Likely cause

Azure is rotating the root certificate that VPN gateways use for P2S. During the transition the gateway presents a server certificate signed by the new (G2) root, and clients need an updated VPN client profile that carries the new root information. Microsoft notes this affects all P2S clients, not only certificate auth, and that in some cases the client OS can distrust the previous root before you have even received the update notice. Clients still using the old profile then can't complete the tunnel, which matches "all users, from one point in time, regardless of network".

Also worth noting: the event you posted (a connection named vnet-unity4 dialed by SYSTEM, error 628) comes from the built-in Windows VPN client with your IKEv2 profile. The Azure VPN Client app only uses the OpenVPN tunnel type, so reinstalling or updating that app won't change an IKEv2 connection.

What I'd do

Generate a fresh client profile package from the gateway (it must be downloaded now, not reused from an old zip):

Portal: Virtual network gateway > Point-to-site configuration > Download VPN client

or CLI:

     az network vnet-gateway vpn-client generate --resource-group <rg> --name <gateway-name> --processor-architecture Amd64

or PowerShell:

     New-AzVpnClientConfiguration -ResourceGroupName "<rg>" -Name "<gateway-name>" -AuthenticationMethod "EapTls"

On one test machine, install the G2 root certificate included in the new package if it isn't already present, then install the new profile from the WindowsAmd64 folder. The new profile does not overwrite an existing one, so remove the old vnet-unity4 connection first or you may keep dialing the stale profile.
Confirm the client certificate is still in Current User\Personal\Certificates and valid, then connect.
If that works, push the new package to all users with your usual endpoint management tool.

If it still fails with the new profile

In the portal, check the root certificate under Point-to-site configuration is still present and not revoked or expired; if in doubt, delete and re-upload the public key (Base64, no spaces).
Make sure there is no UDR with a default route on the GatewaySubnet.
If you need users back immediately and the cause is the client distrusting the old root, Microsoft's guidance is to install the previous root certificate on the client as a stopgap.

References:

If you post what you see after trying the new profile on one machine, I can help narrow it down further.