Azure P2S Client Auth: Entra, Certificate or RADIUS
Entra sign-in, client certificates and RADIUS need different Azure VPN clients and profiles. Pick the method, then the client, then the profile.
The installer runs, the profile imports, and the connection fails at the sign-in step. Most of these tickets are not a bug in the client: an OpenVPN-compatible application can carry the tunnel and still have no idea how to perform a Microsoft Entra sign-in. The order that avoids the loop is method, then client, then profile. Choose the authentication method the gateway is configured for, pick a client Microsoft documents for that method, and only then generate the profile that client expects. Everything below follows that order.
Start from the method, not the installer
The gateway is configured with one or more tunnel types and authentication methods. That pair, not the file extension sitting on your desktop, decides which clients are supported.
Write the pair down before you download anything, because the supported matrix is narrow and a wrong start costs an afternoon.
Here is the mapping I keep in the deployment notes:
| Authentication | Tunnel type | Documented client |
|---|---|---|
| Microsoft Entra ID | OpenVPN | Azure VPN Client on Windows and macOS |
| Client certificate | OpenVPN or IKEv2 | Azure VPN Client, documented OpenVPN client, native IKEv2 client, strongSwan on Linux |
| RADIUS | IKEv2 or OpenVPN, per the current matrix | Native IKEv2 client, strongSwan, or the OpenVPN client the matrix names |
Read that table as a constraint, not a menu. Each row is a documented combination, and mixing a client from one row with the method from another is the exact failure this article exists to prevent.
Entra ID means OpenVPN plus the Azure VPN Client
For Entra authentication on point-to-site, the supported arrangement uses the OpenVPN tunnel type and the Azure VPN Client. A generic username and password dialog is not a substitute for that integration, and Windows native IKEv2 is not an interchangeable way to perform the same login. If a third-party client offers an Entra or Azure AD option, verify it against current Microsoft documentation rather than the label. The label is marketing, while the documented combination is the contract.
On macOS the Azure VPN Client is the documented path for this method as well.
Certificates need a client credential, not just a root
Certificate authentication is a separate supported model, and it works with OpenVPN clients Microsoft documents and with the Azure VPN Client on supported platforms. On Windows the Azure VPN Client is not Entra-only: it has a documented certificate workflow too. What it needs is the intended client certificate with a usable private key, trusted by the gateway. The gateway's trusted root is not a client credential, and the issuer's signing key never belongs in a client package.
Check the chain before you debug the profile. A certificate issued by a root the gateway does not trust produces a failure that looks like a bad profile and is really a trust problem.
Keep the private key non-exportable where the platform allows it, and test with the certificate actually installed for the current user.
RADIUS is a backend choice with its own combinations
RADIUS moves the credential decision to a server you run, and it is documented with specific tunnel types and clients. It is not automatically the right answer because the estate has several operating systems. Identify what the actual client can present before you change the gateway's authentication policy, because switching the gateway to RADIUS does not retrofit every existing profile. The client still has to be able to prompt for, or supply, those credentials.
If a mixed estate is the driver, solve it per platform instead of weakening the gateway policy for everyone.
Linux after the 2026 preview retirement
Microsoft's Linux retirement guidance gives 31 August 2026 as the retirement date for the Linux Azure VPN Client preview, so as of November 2026 that preview is behind you. Existing installations may keep working, but they no longer receive support, updates or security fixes. Do not hand out an old Linux installer as a supported new deployment. This is a client retirement, not a retirement of Azure VPN Gateway or of the Windows and macOS clients.
The documented Linux alternatives are an OpenVPN client with certificate authentication, or strongSwan with IKEv2 and certificate or RADIUS authentication. Both are different configurations that need organisational approval, not a conversion you get by renaming the old Entra profile.
If Entra sign-in is mandatory for policy reasons, the owner has to choose a supported platform or an approved alternative design. That is a decision, not a workaround.
Generate the profile and run four checks
Generate the client configuration from the intended gateway once the combination is settled, and import the representation documented for that client and method. The generic OpenVPN folder and the Azure VPN Client XML profile are not interchangeable. If the gateway deliberately enables several authentication types, pick the matching profile and credential path rather than expecting one connection to satisfy all of them. Then run the checks in this order:
- The supported client imports the generated profile without editing it.
- The intended identity authenticates with the method that profile expects.
- The required route and resolver policy appear on the client.
- The permitted application reaches its private resource.
A successful import proves neither authentication compatibility nor private-resource authorization, which is why those four checks stay separate.