Cloud & infrastructure

Azure point-to-site VPN with Entra ID sign-in, MFA and the Azure VPN Client

Configure an Azure VPN Gateway point-to-site connection that signs users in with Microsoft Entra ID, enforce MFA, and deploy the Azure VPN Client profile with Intune.

12 min read
On this page

To give remote users VPN access to an Azure virtual network with their Microsoft Entra ID account, configure the point-to-site settings on a route-based VPN gateway with the OpenVPN tunnel type, Microsoft Entra ID authentication and the Microsoft-registered Audience value c632b3df-fb67-4d84-bdcf-b95ad541b5c8, then import the generated profile into the Azure VPN Client on Windows 11 or macOS. MFA comes from Conditional Access, and Intune can push the profile to Windows devices through a custom OMA-URI setting. No app registration or admin consent is needed when you use the Microsoft-registered app ID.

Who this is for and what you will have

This guide is for cloud and identity administrators replacing certificate-based or third-party client VPNs with Entra ID sign-in, and for teams still running the older manually registered Azure VPN app who need to move before it retires. At the end you will have:

  • A point-to-site configuration on your VPN gateway that authenticates users against your tenant.
  • The Azure VPN Client installed and a profile imported on Windows and macOS.
  • A Conditional Access approach for MFA and a way to restrict which users can connect.
  • An Intune configuration profile that deploys the VPN connection to managed Windows devices.
  • A troubleshooting path for the errors users actually report.

Point-to-site VPN is one option for remote access. If you are weighing it against identity-aware alternatives, the zero trust remote access architecture post covers the wider design.

How Entra ID authentication works for point-to-site

The gateway trusts tokens issued by your tenant for one Audience value. Three kinds of value exist:

App ID typeAudience valueNotes
Microsoft-registeredc632b3df-fb67-4d84-bdcf-b95ad541b5c8Same value for Azure Public, Government, Germany and 21Vianet. No registration or consent.
Manually registered (Azure Public)41b23e61-6c1e-4545-b367-cd054e0ed4b4Retires March 31, 2028 in Azure Public and March 31, 2029 in Azure Government and 21Vianet.
CustomYour own app registration's client IDUsed to restrict access by users and groups.

A gateway supports only one Audience value at a time. The latest Azure VPN Clients for Windows and macOS work with all three types, so you can change the gateway without replacing the client software.

The Microsoft-registered option is the default choice for new deployments. Use a custom audience only when you need to control who can connect at the application level, which is covered in the Conditional Access section.

Prerequisites

  • A compatible VPN gateway. The gateway can't use the Basic SKU or the policy-based VPN type. If you need one, create a route-based gateway first; point-to-site is configured afterwards on the same resource.
  • A client address pool that doesn't overlap the virtual network or any on-premises range your users connect from. The minimum is a /29 for active-standby gateways and a /28 for active-active.
  • Your tenant ID, from the Entra admin center overview page.
  • Supported clients. The Azure VPN Client for Windows is supported on Windows 11 (x64, x86 and ARM64). The macOS client supports macOS 15, 14, 13 and 12 on x64 and Arm64, and isn't available in France and China. The Linux client retired on August 31, 2026 and has no Entra ID replacement.
  • For Intune deployment: devices enrolled in Intune MDM and the Azure VPN Client already installed.
  • For Conditional Access: an account with at least the Conditional Access Administrator role.

Step 1: Configure point-to-site on the gateway

In the Azure portal, open the virtual network gateway, select Point-to-site configuration, then Configure now, and set:

  • Address pool: for example 172.16.201.0/24
  • Tunnel type: OpenVPN (SSL)
  • Authentication type: Microsoft Entra ID (older portal views may still say Azure Active Directory)
  • Tenant: https://login.microsoftonline.com/<tenant-id> with no trailing backslash
  • Audience: c632b3df-fb67-4d84-bdcf-b95ad541b5c8
  • Issuer: https://sts.windows.net/<tenant-id>/ including the trailing slash; without it, connections can fail

Ignore the Grant administrator consent for Azure VPN client application link. It only applies to the manually registered app. Select Save.

The same configuration in Azure PowerShell:

$tenantId = '<tenant-id>'
$gw = Get-AzVirtualNetworkGateway -Name 'vpngw-hub' -ResourceGroupName 'rg-hub-network'
 
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw `
    -VpnClientAddressPool '172.16.201.0/24' `
    -VpnClientProtocol OpenVPN `
    -VpnAuthenticationType AAD `
    -AadTenantUri "https://login.microsoftonline.com/$tenantId" `
    -AadIssuerUri "https://sts.windows.net/$tenantId/" `
    -AadAudienceId 'c632b3df-fb67-4d84-bdcf-b95ad541b5c8'

-VpnAuthenticationType also accepts Certificate and Radius, and you can combine types. If you do, the profile package contains a separate file per authentication type.

If the gateway is in a hub and users need to reach spoke networks, the peerings must allow gateway transit from the hub and use the remote gateway from each spoke. The hub-and-spoke network with Azure Firewall post shows the peering and routing settings.

Step 2: Download the VPN client profile package

At the top of the Point-to-site configuration page, select Download VPN client. Generation takes a few minutes, and the zip file is named after the gateway. Inside, the AzureVPN folder contains azurevpnconfig.xml when only Entra ID authentication is configured, or azurevpnconfig_aad.xml when several authentication types are enabled.

If the AzureVPN folder is missing, the gateway isn't set to OpenVPN with Entra ID authentication. Regenerate the package whenever you change the tunnel type, authentication type or Audience; existing clients don't update themselves.

Step 3: Install the Azure VPN Client and import the profile

On Windows, install the client from the Microsoft Store, from the install files at https://aka.ms/azvpnclientdownload, or with WinGet:

winget install Microsoft.AzureVPNClient --source winget

The client must be allowed to run in the background. Then open it, select + and Import, browse to the AzureVPN folder, select the XML file and select Save. Select the profile and Connect, and sign in with an Entra ID account. A successful connection shows Connected.

For scripted imports, copy the XML into %userprofile%\AppData\Local\Packages\Microsoft.AzureVpn_8wekyb3d8bbwe\LocalState and run azurevpn -i azurevpnconfig.xml; add -f to force the import.

On macOS, install the Azure VPN Client from the App Store, select Import, choose the XML file, and check that Certificate Information shows DigiCert Global Root G2 before you save.

To turn on Always On for a Windows profile, open VPN Settings, select the disconnected profile and tick Connect automatically.

Step 4: Enforce MFA with Conditional Access

Microsoft documents two ways to require MFA for VPN users: per-user MFA, which prompts for every application in the tenant, and Conditional Access, which Microsoft recommends. With Conditional Access you have three practical designs.

Option A: a baseline policy for all resources

Microsoft recommends a baseline policy that requires MFA for all users and All resources without resource exclusions. That policy also covers VPN sign-ins, so for many tenants nothing VPN-specific is needed.

Option B: a policy that targets the VPN application

Microsoft's VPN article creates a policy for selected users with Target resources set to Select resources and the Azure VPN Client app, granting access with Require multifactor authentication. When the gateway uses the Microsoft-registered Audience, you may not find an app by that name in the picker. Microsoft's Conditional Access documentation says applications missing from the picker can only be covered through All resources or by adding the missing service principal with New-MgServicePrincipal or Microsoft Graph. The VPN documentation doesn't describe that step for this app, so test it in report-only mode before relying on it.

Option C: a custom audience app

A custom audience gives you an enterprise application you own. Microsoft's steps:

  1. In App registrations, create a single-tenant app. Its Application (client) ID becomes the gateway's Audience.
  2. Under Expose an API, add a scope (for example p2s-vpn1, Admins only, Enabled).
  3. Select Add a client application and add c632b3df-fb67-4d84-bdcf-b95ad541b5c8 with the scope authorized.
  4. In Enterprise applications, open the app, set Assignment required to Yes, and assign the users or groups allowed to connect. Group members must be direct members; nested groups aren't supported.
  5. Set the gateway Audience to the custom client ID and redownload the profile.

This is also how you restrict who can connect at all. With a custom audience, add an applicationid element to the profile so users aren't prompted repeatedly:

<aad>
   <audience>{customAudienceID}</audience>
   <issuer>https://sts.windows.net/{tenant ID value}/</issuer>
   <tenant>https://login.microsoftonline.com/{tenant ID value}/</tenant>
   <applicationid>c632b3df-fb67-4d84-bdcf-b95ad541b5c8</applicationid>
</aad>

Whatever you choose, keep session lifetime in mind. The client renews its access token about every hour using its refresh token. Microsoft recommends a sign-in frequency longer than two hours for VPN users and warns against Every time, which forces interactive sign-in every hour and causes disconnects.

Step 5: Deploy the profile with Intune

Intune can push the connection to Windows devices as a custom VPNv2 profile. Build the XML first:

<VPNProfile>
  <RememberCredentials>true</RememberCredentials>
  <AlwaysOn>true</AlwaysOn>
  <TrustedNetworkDetection>contoso.com</TrustedNetworkDetection>
  <PluginProfile>
    <ServerUrlList>azuregateway-<id>.vpn.azure.com;ContosoVPN</ServerUrlList>
    <CustomConfiguration>
      <!-- paste the full contents of azurevpnconfig.xml here -->
    </CustomConfiguration>
    <PluginPackageFamilyName>Microsoft.AzureVpn_8wekyb3d8bbwe</PluginPackageFamilyName>
  </PluginProfile>
  <RegisterDNS>false</RegisterDNS>
</VPNProfile>

Copy the server name from the ServerUrlList entry in your downloaded azurevpnconfig.xml, put a friendly name after the semicolon, and paste the whole downloaded file between the CustomConfiguration tags. Note the value in the name element; users see it as the connection name.

In the Intune admin center, go to Devices > Configuration profiles > Create profile, choose Windows 10 and later, Templates > Custom, and add a setting:

  • OMA-URI: ./User/Vendor/MSFT/VPNv2/<connection name>/ProfileXML
  • Data type: String (XML file), then upload the file

Assign it to a user group. On Windows 11, Microsoft documents a known issue where the VPN disconnects during Intune syncs because Windows regenerates the profile XML differently from the uploaded file, so Intune deletes and reprovisions it. The fix is to export the XML from a working device and upload that version:

$vpns = Get-CimInstance -Namespace root\cimv2\mdm\dmmap -ClassName MDM_VPNv2_01
$vpns[0].InstanceID
[System.IO.File]::WriteAllText("VPN-Corrected.xml", $vpns[0].ProfileXML)

Optional profile settings: DNS and routes

Edit the downloaded XML before you import or deploy it. Custom DNS servers and extra routes go inside clientconfig:

<azvpnprofile>
<clientconfig>
    <dnsservers>
        <dnsserver>10.100.0.4</dnsserver>
    </dnsservers>
    <includeroutes>
        <route>
            <destination>10.200.0.0</destination><mask>16</mask>
        </route>
    </includeroutes>
</clientconfig>
</azvpnprofile>

Split tunnelling is the default. You can force all traffic into the tunnel with a 0.0.0.0/0 include route on recent clients, but Microsoft notes that internet connectivity isn't provided through the VPN gateway, so internet-bound traffic is dropped. With Entra ID authentication, the client applies DNS through Name Resolution Policy Table entries, so the servers don't appear in ipconfig /all; check them with Get-DnsClientNrptPolicy. If users must resolve private endpoint names, the private endpoint DNS with Private Resolver post explains why the virtual network's DNS servers need to be the resolver's inbound endpoint.

Migrating from the manually registered app

If your gateway uses 41b23e61-6c1e-4545-b367-cd054e0ed4b4 or another manually registered value, change the gateway Audience to c632b3df-fb67-4d84-bdcf-b95ad541b5c8 and save. Microsoft states this causes less than five minutes of downtime. Then either edit each client (... > Configure, change Audience, Save) or regenerate and redistribute the profile. If you use a custom audience, you don't need to change the gateway: add c632b3df-fb67-4d84-bdcf-b95ad541b5c8 as another authorized client application on your app registration.

Verification

  • The client shows Connected and the profile's Audience matches the gateway.
  • The Entra sign-in logs show the user's sign-in with the Conditional Access result you expect.
  • Get-DnsClientNrptPolicy lists the DNS servers you configured, and a VM in the virtual network answers on an allowed port.
  • On Azure VPN Client 4.0.0.0 or later, ... > Prerequisites > Run Prerequisites Test passes.

Troubleshooting

Start with the client. Open Status Logs from the arrows icon at the bottom right; errors are shown in red. For Entra ID profiles, try ... > Configure > Clear Saved Account > Save, then reconnect. Diagnose > Run Diagnosis tests internet access, whether the Entra ID authentication endpoint is reachable, and whether the VPN server resolves and responds. Show Logs Directory opens the log files.

"Your authentication with Microsoft Entra is expired. You need to re-authenticate in Entra to acquire a new token." The refresh token expired or became invalid: the default 90-day lifetime ended, a sign-in frequency policy applied, the user's credentials changed, sessions were revoked, or a managed device became non-compliant. Check the user's sign-in logs, and have the user reconnect to sign in interactively.

Users aren't prompted to sign in again after disconnecting. That is by design while the refresh token is valid. To force a prompt on every connection, set cachesigninuser to false in the aad section of the profile (client 4.0.0.0 or later).

"Dialing VPN connection ..., Status = VPN Platform didn't trigger connection" with RasClient error 1460 in Event Viewer. The client isn't allowed to run in the background. Turn on Let apps run in the background in Windows privacy settings.

Repeated sign-in prompts with a custom audience. The profile is missing the applicationid element shown in Step 4.

No AzureVPN folder in the package, or "File download error. Target URI is not specified." The gateway isn't OpenVPN with Entra ID authentication, or the gateway type or VPN type is wrong; it must be VPN and RouteBased.

Connected, but private DNS names don't resolve. The virtual network uses the Azure-provided DNS server, which VPN clients can't query. Point the virtual network DNS setting at a DNS Private Resolver inbound endpoint; the gateway pushes that address to clients.

Closing checklist

  • Route-based, non-Basic gateway with OpenVPN and a non-overlapping client address pool.
  • Tenant URL without a trailing backslash; Issuer with a trailing slash; Audience c632b3df-fb67-4d84-bdcf-b95ad541b5c8 or your custom app ID.
  • Profile package regenerated after every gateway change.
  • MFA enforced by a baseline All resources policy or a VPN-scoped policy, with sign-in frequency above two hours.
  • Custom audience with Assignment required if only some users may connect.
  • Intune VPNv2 profile using the Windows-exported XML to avoid sync disconnects.
  • Manually registered Audience values migrated before March 31, 2028.

References

Questions people ask

Do I still need to register the Azure VPN Client app in Entra ID?

No. Use the Microsoft-registered Audience value c632b3df-fb67-4d84-bdcf-b95ad541b5c8 on the gateway. It has global consent, so there is no admin consent step. The older manually registered app values retire on March 31, 2028 in Azure Public.

Can Linux clients connect to a P2S gateway that uses Entra ID authentication?

No. The Azure VPN Client for Linux (Preview) retired on August 31, 2026, and the supported OpenVPN and strongSwan alternatives don't support Entra ID authentication for VPN Gateway. Linux users need a gateway authentication method such as certificates.

Why do VPN users get disconnected and asked to sign in again?

The client needs a valid refresh token to renew its access token about every hour. When the refresh token expires or is revoked, for example by a sign-in frequency policy, a password change or a non-compliant device, the tunnel drops. Microsoft recommends a sign-in frequency longer than two hours and never "every time".

Does Entra ID authentication work on the Basic VPN Gateway SKU?

No. Microsoft lists the Basic SKU and the policy-based VPN type as incompatible with Entra ID authentication for point-to-site. Use a route-based gateway on a VpnGw SKU, preferably an AZ SKU.

Azure VPN GatewayEntra IDAzure VPN ClientConditional AccessMicrosoft Intune
  1. Replace Require Approved Client App with the App Protection Policy Grant

    Policies using the retired approved client app grant are now read-only. Find them, build replacements that require an app protection policy, test in report-only and cut over.

  2. Silent BitLocker encryption with Intune and recovery key escrow to Entra ID

    Encrypt Windows devices with no user prompts through an Intune disk encryption policy, and make BitLocker wait until the recovery password is stored in Microsoft Entra ID.

  3. Windows Autopilot error codes: fix 0x80180014, 0x800705b4 and more

    Look up Windows Autopilot and Intune enrollment error codes, including 0x80180014, 0x800705b4, 0x801c03ea and 80180018, and apply the fix Microsoft documents for each.