Azure VPN Client Linux Retires August 31, 2026—Entra ID Has No Replacement

Entra ID-authenticated Linux Point-to-Site users do not have a like-for-like supported client replacement.
Microsoft will retire the preview Azure VPN Client for Linux package, microsoft-azurevpnclient, on August 31, 2026. Organizations using Microsoft Entra ID authentication with Azure VPN Gateway Point-to-Site connections must redesign either the authentication method or the access path; installing OpenVPN or strongSwan will not preserve the existing Linux Entra ID sign-in flow.
WindowsForum readers have seen other Microsoft VPN retirements recently. Our reports on the Microsoft Defender Privacy Protection VPN documented its February 28, 2025 departure from Microsoft 365 Personal and Family subscriptions and the resulting search for alternatives. This Azure change is separate: it concerns an enterprise Azure VPN Gateway client package for Linux, has a different deadline, and requires administrators to examine gateway authentication rather than shop for a generic privacy VPN.
Microsoft says the Linux Azure VPN Client remained in preview and will not progress to general availability. The generally available Windows and macOS Azure VPN Clients are unaffected, which may make the Linux deadline easy to miss in Windows-first organizations.

Inventory the Authentication Dependency Before Choosing a Client​

The first task is not selecting OpenVPN or strongSwan. It is determining whether Linux connectivity depends on a feature neither replacement provides.
Microsoft states that the open-source OpenVPN and strongSwan clients do not support Microsoft Entra ID authentication with Azure VPN Gateway Point-to-Site connections. On Linux, that authentication option depended on the retiring Azure VPN Client.
That creates three migration cases:

Current requirement	Supported direction	Gateway consequence
OpenVPN with certificate authentication	Move to the open-source OpenVPN client.	No gateway change is required if OpenVPN and certificate authentication are already configured.
IKEv2 with certificate or RADIUS authentication	Move to strongSwan.	IKEv2 and the selected supported authentication method must be enabled.
Microsoft Entra ID authentication for Linux	Redesign authentication or the access path.	OpenVPN and strongSwan cannot reproduce the existing Linux Entra ID sign-in flow.

Decision checklist: Using Entra ID on Linux: escalate and redesign; OpenVPN plus certificates already configured: migrate to OpenVPN; IKEv2 plus certificates/RADIUS: migrate to strongSwan.
The third row is the hidden migration risk. A replacement client may establish a tunnel in a test environment while still failing the organization’s real requirement: authenticating the user through Entra ID.
Administrators should inventory endpoints and gateway settings. Search software inventories, endpoint-management systems, configuration-management records, and deployment scripts for microsoft-azurevpnclient. For each affected user or device group, record the gateway, tunnel type, authentication method, Linux distribution, owner, and required business resources.
Authentication must be the primary decision point. A device count alone does not reveal whether an OpenVPN deployment is a straightforward client migration or an identity redesign.

OpenVPN Is the Lowest-Change Route Only for Certificate Users​

OpenVPN is the most direct replacement when Azure VPN Gateway is already configured for the OpenVPN tunnel type with certificate authentication. Microsoft says those Linux endpoints can move to the open-source OpenVPN client without a gateway change.
That does not make the endpoint transition automatic. As WindowsForum operational guidance, administrators should plan to obtain suitable client configuration from the gateway, package the client and configuration for supported Linux distributions, verify certificate availability, and test access before removing the Microsoft client. The exact deployment process will depend on the organization’s certificate infrastructure and device-management tooling.
A practical migration plan is:

1. Confirm that the affected gateway and users already rely on OpenVPN with certificate authentication.
2. Prepare replacement client configurations using the organization’s normal Azure and certificate-administration procedures.
3. Package the open-source OpenVPN client and required configuration for each managed Linux distribution.
4. Determine in a lab whether the old and new packages and profiles can coexist safely; do not assume coexistence across every distribution.
5. Pilot tunnel establishment, name resolution, routing, and access to required resources.
6. Define a temporary rollback procedure appropriate to the organization’s environment.
7. Deploy in controlled waves after representative users complete their normal workflows.
8. Remove microsoft-azurevpnclient and its deployment references after the migration is accepted.

These are WindowsForum operational recommendations, not a Microsoft-prescribed rollout sequence. Profile generation, profile distribution, package behavior, and rollback mechanics vary among environments.
The key condition is certificate readiness. An organization currently using Entra ID cannot call OpenVPN a client-only swap merely because the gateway supports the OpenVPN protocol. It must introduce and operate certificate authentication, including enrollment, delivery, renewal, revocation, and support.
That may be manageable for centrally administered workstations. It becomes more complicated when access includes contractors, developer-owned computers, temporary systems, or devices outside the normal certificate-management boundary.

strongSwan Requires an IKEv2 and Authentication Decision​

strongSwan is the other identified Linux replacement. It uses IKEv2 and can authenticate with certificates or RADIUS. Azure VPN Gateway must have IKEv2 enabled for this route.
Teams should verify the gateway’s current configuration before treating client packaging as the main task. The available facts do not establish that administrators can enable IKEv2 and OpenVPN simultaneously on every relevant gateway configuration, so coexistence should not be assumed when designing the cutover.
RADIUS may be useful where an organization already operates a suitable authentication service and does not want to distribute client certificates. It must not be presented as native Entra ID support under another name. strongSwan with RADIUS is a different authentication design from the Entra ID experience supplied by the retiring Azure VPN Client.
Mixed-platform organizations may consequently operate different access methods. Windows and macOS users can continue using their unaffected, generally available Azure VPN Clients, while Linux users may move to strongSwan with certificates or RADIUS. That split should be documented in support procedures, access reviews, and identity-governance controls.
As with OpenVPN, WindowsForum recommends a representative pilot rather than prescribing exact profile-generation or deployment commands. Test the gateway and authentication prerequisites first, then validate routing, DNS, resource access, credential revocation, and recovery procedures.

Entra-Dependent Linux Users Need an Access Redesign​

Organizations that require Entra ID authentication from Linux face a policy decision, not just an engineering task. Neither open-source replacement reproduces that Azure VPN Gateway authentication capability.
The supported directions described by the available guidance are:

• Replace Entra ID authentication for the affected Linux population with certificate authentication and use OpenVPN or strongSwan.
• Introduce RADIUS authentication and use strongSwan over IKEv2.
• Design another controlled access path that does not depend on an Entra-authenticated Azure VPN Client running on Linux.

Because the Windows and macOS clients are unaffected, an organization could evaluate whether a supported device on one of those platforms fits its own access architecture. That is an organizational design option, not an explicit Microsoft migration recommendation for Linux users.
This limitation deserves early escalation to security and identity teams. Moving from Entra ID to certificates or RADIUS changes how access credentials are issued, audited, disabled, renewed, and recovered. A tunnel can work technically while producing an unacceptable governance or offboarding process.
The recent Defender VPN retirement coverage on WindowsForum offers a useful caution about terminology. In reports including “Microsoft Defender VPN to Retire: What Users Should Know” and “Microsoft Retires Free VPN in Microsoft 365,” the practical question was what consumer privacy service users might choose next. Here, a commercial VPN subscription is not a substitute. The Linux client connects users to organizational Azure resources, and its authentication constraints must be addressed inside the enterprise access design.

Remove the Retiring Package From Configuration Sources​

Finding installed copies is only half of the cleanup. Identify microsoft-azurevpnclient in golden images, provisioning scripts, configuration-management roles, endpoint baselines, internal package catalogs, onboarding instructions, support runbooks, and disaster-recovery documentation.
After users have migrated and the replacement has passed the organization’s acceptance checks, remove or update those references. Otherwise, a rebuilt device or automated remediation job could reinstall or request the retired package after the active fleet appears clean.
WindowsForum recommends assigning owners to both sides of this work:

• Endpoint teams should locate installed packages and automated deployment references.
• Network teams should verify gateway tunnel and authentication settings.
• Identity teams should approve certificate or RADIUS lifecycle controls.
• Service owners should confirm that representative applications remain reachable.
• Documentation owners should remove obsolete installation and troubleshooting instructions.

Do not base the project on an assumed repository-removal date or assumed behavior of existing installations after August 31, 2026. The established fact is that the package retires and is no longer supported on that date. Complete the migration before the deadline rather than treating unsupported behavior as a continuity plan.

Test Real Workloads Before Removing the Existing Path​

A successful connection indicator is not sufficient evidence of a completed migration. WindowsForum recommends testing users from each gateway, Linux distribution, authentication model, and significant resource-access pattern.
Validate authentication, tunnel establishment, DNS resolution, route handling, and access to required Azure resources. Include certificate renewal or revocation behavior where certificates are introduced, and test the relevant operational procedures where RADIUS is selected.
Rollback planning should be environment-specific. Before changing a pilot device, document its working configuration and define the conditions that pause or reverse the pilot. Whether two clients can remain installed together, how profiles are distributed, and how an endpoint is restored must be verified by the organization rather than assumed from Microsoft’s retirement notice.
Once the pilot succeeds, deploy in waves and classify failures by authentication method. A missing certificate, unavailable RADIUS path, disabled IKEv2 configuration, and attempted Entra ID use through an unsupported replacement are different problems.
By August 31, 2026, each affected Linux user needs a validated certificate- or RADIUS-based connection or a redesigned access path. Windows and macOS remain unaffected, but that does not solve the Linux authentication gap.

Frequently Asked Questions​

When will Microsoft retire Azure VPN Client for Linux?​

Microsoft will retire the preview microsoft-azurevpnclient package on August 31, 2026.

Can Linux users replace it with OpenVPN and keep Entra ID authentication?​

No. The open-source OpenVPN client does not support Microsoft Entra ID authentication for these Azure VPN Gateway Point-to-Site connections. OpenVPN is a suitable direction when certificate authentication is configured.

Does strongSwan support Entra ID authentication?​

No. The identified strongSwan options use certificates or RADIUS over IKEv2. Azure VPN Gateway must have IKEv2 enabled.

Are the Windows and macOS Azure VPN Clients retiring too?​

No. Microsoft’s generally available Azure VPN Clients for Windows and macOS are unaffected by this Linux package retirement.

Is this the same as the Microsoft Defender Privacy Protection VPN retirement?​

No. WindowsForum’s earlier reports covered the Defender VPN feature leaving Microsoft 365 Personal and Family subscriptions on February 28, 2025. This retirement concerns the Azure VPN Client preview package for Linux and Azure VPN Gateway Point-to-Site access.

What should Entra ID-dependent Linux organizations do first?​

Escalate the issue to network, security, and identity owners. There is no like-for-like supported Linux client replacement, so the organization must choose a new authentication method or redesign the access path.

Should administrators wait to see whether installed clients still work?​

No continuity plan should depend on unspecified post-retirement behavior. Inventory the package and its authentication dependencies now, test a supported design, update automation and documentation, and finish the transition before August 31, 2026.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Azure VPN Client for Linux - Retirement Overview and Migration Guide - Azure VPN Gateway | Microsoft Learn

   Learn how to migrate from the Azure VPN Client for Linux to a supported client for Azure VPN Gateway P2S connections.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Microsoft Defender VPN to Retire: What Users Should Know | Windows Forum

   It’s time to update those virtual whiteboards because Microsoft has decided to retire its Microsoft Defender-powered VPN service from Microsoft 365...

   windowsforum.com