Microsoft is pulling the plug on SSTP at the Azure VPN Gateway. As of March 31, 2026, SSTP can no longer be newly enabled. As of March 31, 2027, existing SSTP connections will stop working entirely. The official guidance points to IKEv2 or OpenVPN — but in the real world, neither is a clean replacement for what SSTP delivered. IKEv2 relies on UDP ports that are blocked in many networks. OpenVPN breaks the entire Always On VPN deployment model. This isn’t just a protocol swap. It’s the next step in Microsoft’s broader move away from traditional client VPN — and a strong reason to seriously evaluate Microsoft Entra Private Access as the successor.
🔌 What’s Actually Happening?
The Azure VPN Gateway has supported three protocols for Point-to-Site connections for years: SSTP, IKEv2, and OpenVPN. Among these, SSTP was always the “just works” option — natively built into Windows since Windows 7, running over TCP 443, and therefore able to pass through virtually any firewall or proxy.
That’s exactly the protocol Microsoft is now retiring. The reasoning in the official Learn article is refreshingly blunt: “Due to limited capability and suboptimal performance, we’re retiring SSTP protocol.”
The hard deadlines:
- March 31, 2026 — Enabling SSTP on VPN Gateways is no longer supported
- March 31, 2027 — Existing SSTP connections will be suspended and stop working
There’s also a limitation that’s been in place all along: SSTP is capped at 128 concurrent connections per gateway, regardless of the SKU.
🛤️ The Official Migration Paths — And Their Problems
Microsoft recommends two approaches:
Option 1 — Enable IKEv2 alongside SSTP. The two protocols can coexist on the same gateway. The Windows client will attempt IKEv2 first and fall back to SSTP if it fails. This sounds elegant — but it’s only useful during the transition period. After March 31, 2027, the fallback disappears.
Option 2 — Switch to OpenVPN. Since both SSTP and OpenVPN are TLS-based, they cannot run on the same gateway simultaneously. Switching means disconnecting existing clients until the new profile is deployed.
Both options come with significant trade-offs. Let’s unpack them.
⚠️ Why IKEv2 Is Not a Clean Answer for Mobile Clients
IKEv2 uses UDP 500 and UDP 4500. Microsoft says this explicitly in their documentation: “IKEv2 uses non-standard UDP ports so you need to ensure that these ports are not blocked on the user’s firewall.”
In theory, that’s just a firewall rule. In practice, it’s a support nightmare:
- Public Wi-Fi (airports, trains, cafés, hotels) frequently blocks everything except TCP 80/443
- Mobile carriers in some regions filter or throttle UDP 500/4500 to the point where the tunnel becomes unstable
- Guest networks at client sites often have restrictive firewalls that you, as the VPN operator, have zero control over
- Carrier-grade NAT can interfere with IPsec NAT traversal depending on the implementation
This was always the killer argument for SSTP: TCP 443 goes through everywhere. When that property disappears and the replacement relies on UDP ports that fail in exactly the scenarios where you need VPN the most — the migration from SSTP to IKEv2 isn’t a modernization. It’s a downgrade.
🔒 What About OpenVPN? Spoiler: No More AOVPN.
At first glance, OpenVPN looks like the more elegant alternative. TCP 443 like SSTP, so it’s firewall-friendly. Microsoft even offers the Azure VPN Client as a Store app that speaks OpenVPN to the Azure VPN Gateway and supports Entra ID authentication including Conditional Access.
Sounds great — until you realize what you’re giving up.
The hard fact: the Windows-native VPN client — the foundation that Always On VPN (AOVPN) is built on (CSP VPNv2, Add-VpnConnection, the XML profiles deployed via Intune) — supports exactly these tunnel types: PPTP, L2TP/IPsec, SSTP, IKEv2, and plug-in-based third-party protocols via the UWP VPN Plugin Platform. OpenVPN is not on that list.
This means: the moment you switch to OpenVPN, you lose the entire AOVPN feature set — Device Tunnel, User Tunnel with AlwaysOn="true", Pre-Logon connectivity, Trusted Network Detection, Traffic Filters. The Windows VPN stack simply cannot speak OpenVPN.
On the client side, you’re left with three options, all with limitations:
Azure VPN Client (Microsoft Store App)
The Microsoft-recommended path for Azure. Imports the XML profile from the Configuration Package, supports Entra ID auth and Conditional Access. But it runs in user context — no Device Tunnel, no Pre-Logon, no classic auto-connect behavior. The user has to manually initiate the connection. Deployment via Intune works (Store App + profile separately), but it’s no longer an AOVPN profile.
OpenVPN Community Client
The “real” OpenVPN client from openvpn.net. Works with the OVPN file from the Azure Configuration Package, but requires packaging as a Win32 app in Intune, its own update strategy, and does not support Entra ID auth — certificates or RADIUS only. Additional third-party software in your managed environment that needs to be maintained.
OpenVPN Connect (Commercial)
Same functionality, different UI, same limitations.
For all three variants: no Device Tunnel. If you rely on AOVPN today for Pre-Logon scenarios — remote management outside the office, GPO application before user login, password reset via the logon screen — then OpenVPN is simply not an option. Device Tunnel requires IKEv2 with a machine certificate. That’s hardcoded in the Windows stack.
📊 The Sobering Overview
When you lay the three official migration paths side by side, each has a fundamental problem:
| Path | Problem |
|---|---|
| IKEv2 | UDP 500/4500 are blocked in public Wi-Fi and restrictive networks — exactly where VPN is needed most |
| OpenVPN | Breaks the entire AOVPN deployment model. No Device Tunnel. Requires additional client software or the Store app. No native Windows VPN stack integration. |
| Keep SSTP | Only works until March 31, 2027 at the latest. Then it’s dead. |
None of these three paths delivers a true, equivalent replacement for what AOVPN+SSTP provides today. And that, to me, is the real takeaway: Microsoft is removing the convenient path without offering an equally convenient successor — because the strategic answer, from Microsoft’s perspective, isn’t a VPN protocol at all. It’s an entirely different access model.
🔍 Reading Between the Lines
Microsoft is burying SSTP at the gateway level — that’s established fact. What the documentation doesn’t say explicitly, but is the logical consequence in my view: if SSTP disappears server-side, Microsoft is unlikely to invest significant energy into the SSTP client stack in Windows long-term. The RRAS SSTP client won’t vanish tomorrow, but new features, bug fixes, and security investments there will realistically be minimal.
For AOVPN deployments that currently rely on SSTP as the tunnel protocol — whether behind RRAS in Azure or on-premises — that’s at least a reason to question the roadmap.
And it fits suspiciously well with Microsoft’s broader strategy over the past few years:
- VPN concentrators are being positioned as legacy
- Zero Trust, identity-based access, and per-app tunneling are being painted as the future
- With Global Secure Access and specifically Entra Private Access, there’s a SaaS-based successor that covers exactly what client VPN has historically done — without a gateway, without port debates, and without per-user per-device client certificates
🚀 Why Entra Private Access Is the Better Answer
Entra Private Access (EPA) is not a VPN in the traditional sense. It’s identity-based access to private resources, running through a client (the Global Secure Access Client) on one end and Private Network Connectors in the target network on the other. The key advantages over classic P2S VPN:
Transport runs over outbound HTTPS from the connector to Microsoft. No inbound ports, no gateway with a public IP, no SSTP-vs-IKEv2 debate.
Client connectivity also uses outbound HTTPS. This works in exactly the restrictive Wi-Fi environments where IKEv2 fails today.
Conditional Access applies per application. MFA, device compliance, session controls — per app, not per tunnel.
No split-tunneling drama. The client routes only the explicitly published segments and FQDNs. Everything else goes directly to the internet.
Scaling is Microsoft’s problem, not yours. No “max 128 connections per SKU” limitation.
Identity first. The user authenticates with their Entra identity including Passkey or phishing-resistant MFA. No client certificate lifecycle to manage, no RADIUS proxy, no NPS infrastructure to maintain.
For AOVPN deployments that primarily use the User Tunnel for access to file shares, internal web apps, and line-of-business applications, EPA covers this use case cleanly — and arguably better than SSTP ever could.
🧭 What You Should Do Now
If you’re running AOVPN with an SSTP backend today — whether on Azure VPN Gateway or RRAS — here’s my recommended approach:
Take inventory. Which P2S gateways currently use SSTP? How many concurrent connections do you typically see? Which clients are configured for it?
Plan a transitional setup. Enabling IKEv2 alongside SSTP (Option 1 from the Microsoft article) is the lowest-risk intermediate step — as long as you accept that IKEv2 won’t work everywhere.
Separate your use cases. Does the user actually need full-tunnel network access? Or is it really 5–10 internal web apps and a file server? If it’s the latter, EPA is the directly better path.
Set up an EPA pilot. Global Secure Access is part of the Entra Suite (or available as a standalone SKU). Deploy a connector, publish a first application, validate with a test user group.
Document your SSTP exit strategy. March 2027 is the hard deadline. Anyone who hasn’t completed migration by then will be doing the cutover under pressure.
🧠 Final Thoughts
SSTP on the Azure VPN Gateway is dead, and this isn’t an isolated product decision — it’s another building block in Microsoft’s narrative that traditional VPN has had its day. IKEv2 as the official successor fails in the real world due to port restrictions. OpenVPN breaks the entire AOVPN model and introduces third-party software into the Microsoft ecosystem. None of the three migration paths is a fully equivalent replacement — and in my opinion, that’s not an accident. It’s strategy. Microsoft doesn’t want to migrate us to the next VPN protocol. They want to migrate us to a different access model.
My advice: don’t treat the SSTP retirement as a pure migration task (“we just need to switch to IKEv2”). Treat it as an opportunity to fundamentally modernize your access model. Entra Private Access is no longer a nice-to-have — it’s the logical answer to the direction Microsoft is pushing VPN as a whole.
Leave a Reply