Microsoft will retire its preview Azure VPN Client for Linux on August 31, 2026. The move forces organizations that rely on the client for point-to-site (P2S) connections to Azure VPN Gateway to migrate to alternative clients, but with a critical catch: the recommended open-source replacements—OpenVPN and strongSwan—do not support Microsoft Entra ID authentication. For any Linux user currently authenticating via Entra ID, this isn’t just a client swap; it’s an access architecture redesign.

The Retirement at a Glance

The package microsoft-azurevpnclient is the only component being retired. The Windows and macOS Azure VPN Clients remain generally available and unaffected. The retirement does not touch Azure VPN Gateway itself, nor any site-to-site VPN configurations. After August 31, 2026, Microsoft will provide no bug fixes, security patches, or support for the Linux client, and the package is being removed from Microsoft’s Linux software repository.

Why now? The Linux client never progressed beyond public preview, and Microsoft says retiring it aligns with its security and reliability standards. It was limited to Ubuntu 20.04 and 22.04, while the open-source alternatives work across a wider range of distributions. The official guidance is to migrate to either the open-source OpenVPN client (using certificate authentication over the OpenVPN tunnel type) or strongSwan (using certificate or RADIUS authentication over IKEv2). Both are fully supported for Azure P2S connections, but neither can replicate the Entra ID experience.

Who Feels the Impact—and How Hard?

The practical impact depends entirely on how your organization currently authenticates Linux VPN users. A simple device count won’t surface the real risk. You need to inventory the authentication method tied to each gateway. Microsoft’s documentation clearly states: “The OpenVPN and strongSwan open-source clients don't support Microsoft Entra ID (AAD) with the Azure VPN P2S gateway. Microsoft Entra ID authentication on Linux was only available through the Azure VPN Client for Linux.”

If You Use Entra ID on Linux

You lose the sign-in flow. No open-source replacement will let a Linux user authenticate against Entra ID for the VPN tunnel. Your choices boil down to:

  • Move to certificate-based authentication and use OpenVPN or strongSwan.
  • Move to RADIUS authentication (with strongSwan over IKEv2) if your organization already operates a RADIUS service.
  • Re‑platform: give Linux users a supported Windows or macOS device, or a virtual desktop, for this specific access pathway.

Each option carries operational weight. Certificates require enrollment, delivery, renewal, revocation, and support—a non‑trivial lift if you currently lean on Entra ID’s seamless integration. RADIUS can work but isn’t a drop‑in Entra ID substitute; it’s a separate authentication infrastructure with its own lifecycle. And adding a jump‑host or switching users to another OS disrupts workflows and may break automation scripts.

If You Already Use Certificate Authentication

You have the smoothest path. Organizations using OpenVPN with certificates can migrate directly to the open‑source OpenVPN client without changing the gateway configuration. Teams on IKEv2 with certificates or RADIUS can move to strongSwan, provided IKEv2 is enabled on the gateway. No identity recalibration is needed, but you still must package, distribute, and test the new client across your Linux fleet.

The Mixed‑Environment Puzzle

Many enterprises run a mix: Windows and macOS users stay on the unaffected Microsoft clients, while a subset of Linux users may have been relying on the preview client with Entra ID. Post‑retirement, you could wind up with Windows/macOS on Entra ID and Linux on certificates or RADIUS. That split must be documented in support runbooks, access reviews, and identity governance policies. Don’t underestimate the confusion it can cause during incident response or audits.

Why Microsoft Is Dropping the Linux VPN Client

The Azure VPN Client for Linux launched as a preview and never received a general availability stamp. Microsoft has ramped up scrutiny of preview services that lack a clear path to production, often retiring them to concentrate investment elsewhere. The Linux client’s limited distribution support—Ubuntu 20.04 and 22.04 only—may have also played a role. Rather than maintain an under‑adopted preview indefinitely, the company is directing users to mature, open‑source alternatives that cover more Linux variants.

This retirement is separate from other recent Microsoft VPN news. Earlier in 2025, the company retired the Defender Privacy Protection VPN from Microsoft 365 Personal and Family subscriptions, a consumer‑side move. Here, you’re dealing with enterprise access to Azure resources. A commercial VPN service won’t bridge the gap. The fix must come from inside your identity and network architecture.

Crucially, no Linux successor is on the roadmap. Microsoft’s announcement offers no hint of a new native client. For the foreseeable future, Linux P2S connectivity to Azure will depend on OpenVPN or strongSwan—tools that are community‑maintained and require careful admin configuration.

A Migration Roadmap: What to Do Now

The deadline is August 31, 2026. That feels distant, but authentication redesigns and endpoint overhauls take time. Start now with these steps.

1. Inventory Everything That Touches the Retiring Client

Search your configuration management databases, endpoint management tools, software inventories, and deployment scripts for microsoft-azurevpnclient. For every instance, record:

  • The Linux distribution and version
  • The Azure VPN Gateway it connects to
  • The tunnel type and authentication method configured on that gateway
  • The business owners and critical resources accessed

A gateway configured for Entra ID only tells a very different story than one with certificate authentication already enabled. The inventory isn’t a numbers game; it’s an authentication dependency map.

2. Decide on Your Authentication Future

Once you know which endpoints rely on Entra ID, escalate to security, identity, and network teams immediately. The decision tree is straightforward:

  • If currently Entra ID only: redesign authentication. Choose between certificates (with OpenVPN or strongSwan) or RADIUS (with strongSwan). Evaluate your existing PKI maturity or RADIUS footprint. Factor in contractor devices, developer‑owned laptops, and temporary systems that may sit outside standard certificate management.
  • If currently OpenVPN with certificates: opt for the open‑source OpenVPN client. No gateway changes needed.
  • If currently IKEv2 with certificates/RADIUS: opt for strongSwan. Verify that IKEv2 is enabled on the gateway (many gateways can support multiple tunnel types simultaneously, but test this).

Don’t assume coexistence. Test in a lab whether the old and new packages can be installed side‑by‑side on your Linux distributions without profile conflicts.

3. Pilot the New Connection

For the chosen replacement, build a small pilot that mirrors your production landscape:

  • Generate new VPN client profiles from the Azure gateway.
  • Package the replacement client (OpenVPN or strongSwan) with those profiles for your managed distributions.
  • Validate tunnel establishment, DNS resolution, routing, and access to required resources.
  • Specifically test certificate renewal or RADIUS credential rotation—the real‑world lifecycle, not just initial authentication.
  • Document a rollback procedure that restores the working configuration on a pilot device before you begin.

A successful ping or login screen doesn’t certify the migration. Legitimate workloads and off‑boarding/re‑authentication scenarios must pass before you proceed.

4. Roll Out in Waves, Cleaning Up as You Go

Deploy in controlled groups, starting with non‑critical users. Classify failures by authentication method: a missing certificate, an unavailable RADIUS path, a disabled IKEv2 configuration, or an attempted Entra ID login against an unsupported client are all distinct problems with different resolutions.

After each group is migrated and stable, uninstall microsoft-azurevpnclient. Don’t forget the configuration sources that could reintroduce it: golden images, provisioning scripts, endpoint baselines, internal package catalogs, onboarding guides, and disaster recovery documentation. Assign owners to scrub these artifacts so a routine rebuild doesn’t silently reinstall a dead package.

5. Monitor and Support the New Normal

Once all Linux users are on the replacement, update your operational playbooks. Mixed‑platform access—Entra ID for Windows/Mac, certificates for Linux—will likely persist. Make sure your help desk and security operations center recognize the different authentication paths and don’t treat Linux authentication failures like a broken Windows client.

Plan to complete the entire migration before the retirement date. Relying on unsupported behavior after August 31, 2026 is not a continuity strategy.

What Next for Azure Linux VPN?

Microsoft’s message is clear: the future of Linux P2S to Azure is community‑driven. OpenVPN and strongSwan will carry the load, and they support more distributions than the preview client ever did. Organizations gain flexibility—newer Ubuntu releases, Red Hat variants, and specialty distributions all become viable—but they also take on more direct responsibility for client packaging, configuration distribution, and authentication lifecycle management.

There is no indication that Microsoft intends to re‑enter the Linux VPN client space. The unaffected Windows and macOS clients will continue to get updates, but Linux administrators should settle in for a long‑term relationship with open‑source tooling. Watch Azure VPN Gateway updates for any new tunnel-type or authentication enhancements, but treat this retirement as a permanent shift.

In the meantime, the countdown is on: 19 months to inventory, redesign if Entra ID is involved, test, and deploy. The clock started when the announcement dropped—not when your organization discovers a Linux user who can no longer connect.