Azure VPN Gateway SSTP Is Retiring: Why Flipping the Tunnel Type Isn't the Migration You Want

That change clears the deadline. It doesn't change the fact that you're still on a gateway with a hard 128-connection SSTP ceiling, SKU-bound P2S scaling, no cross-cloud reach, and a policy model that stops at the route table. If you're going to touch every client anyway — and switching from SSTP to OpenVPN on the gateway requires exactly that — it's worth spending an afternoon evaluating whether the gateway should stay in the path at all.

This article is the engineering case for moving to OpenVPN Access Server, running inside your own VNet, instead.

What is actually being retired, and when

SSTP is Microsoft's proprietary tunneling protocol. It wraps PPP inside an HTTPS/TLS session on TCP 443, which is why it has been the reliable Windows remote-access option for close to two decades: it goes through almost any firewall.

Here is the timeline that matters:

To find out whether this is your problem, check your gateways directly:

az network vnet-gateway list \
--query "[].{name:name, rg:resourceGroup, sku:sku.name, \
protocols:vpnClientConfiguration.vpnClientProtocols}" \
-o table

Any gateway returning SSTP in protocols is on the clock.

Why "just change the tunnel type" is less free than it looks

Microsoft offers two in-place paths, and each has a real engineering cost.

Adding IKEv2 is the no-downtime option — you set the tunnel type to IKEv2 and SSTP and both run side by side; Windows clients configured for both try IKEv2 first and fall back to SSTP. The catch is transport. IKEv2 needs UDP 500 and UDP 4500. Those ports are routinely blocked on hotel, airport, café, and guest Wi-Fi, and on some mobile carrier networks. That is precisely the population your remote-access VPN exists to serve. You will pass the lab test and then field tickets from the road.

Switching to OpenVPN protocol works over TCP 443 and covers Windows, macOS, Linux, iOS, and Android. But SSTP and OpenVPN are both TLS-based and cannot coexist on the same gateway. So this path means a maintenance window, a new client configuration package, and a redeployment to every endpoint — often with local admin rights required.

Read that last part again, because it is the crux of this article. The cheap-looking migration still costs you a full client redeployment. Once you are paying that price, the incremental cost of pointing those clients at a different server is close to zero — and what you get back is materially different.

What stays broken after the tunnel type change

These are gateway characteristics, not protocol characteristics. Changing the protocol does not touch them.

• The 128-connection SSTP ceiling exists on every SKU. Basic through VpnGw5 — all capped at 128 concurrent SSTP connections. IKEv2/OpenVPN on those same gateways scale to 250 (VpnGw1) through 10,000 (VpnGw5), so the fix for scale is buying a bigger gateway SKU. Your concurrency is a procurement decision, not an engineering one.
• Basic SKU's in-place path is narrower, not nonexistent. As of November 2025, Basic added IKEv2 support, and new Basic gateways are now created with IKEv2 by default — so a same-SKU tunnel-type change is available for the first time. What Basic still doesn't get is OpenVPN protocol, RADIUS, BGP, or zone redundancy, and it never supports Microsoft Entra ID authentication on P2S regardless of tunnel type. So the deadline is solvable on Basic without a SKU change; the scaling, auth, and multi-cloud gaps below are not.
• Authentication is coupled to tunnel type. Microsoft Entra ID authentication on Azure P2S is supported only on the OpenVPN tunnel type (alone, or combined with IKEv2). IKEv2 and SSTP on their own are limited to RADIUS and certificates. If Entra ID auth is the goal, you are already being routed toward the OpenVPN protocol — the question is only whose implementation of it you run.
• Policy granularity stops at routing. Azure P2S gives you routes and NSGs. Per-user and per-group access rules, service-level segmentation, and least-privilege enforcement are things you assemble around the gateway, not inside it.
• It is Azure-only. If you also have AWS, GCP, colo, branch offices, or on-prem, the gateway solves one region of one cloud. Every other environment gets its own tunnel, its own client config, and its own operational surface.

Azure VPN Gateway P2S vs. OpenVPN Access Server

That last row is not a footnote, and I'll come back to it.

What the migration actually looks like

Access Server deploys from the Azure Marketplace as a VM image, in PAYG or BYOL form. Practically:

Deploy from the Azure Marketplace (PAYG) or Deploy Access Server (BYOL) into the VNet (or a hub VNet) that your users need to reach. Give it a public IP and a DNS name so certificates and client profiles stay stable. Sign up for an account on openvpn.net and deploy with the AS Link if you want OpenVPN to provide domain name and SSL certificate.

Wire up identity. Configure SAML against Entra ID (or LDAP/RADIUS if that's your existing SSTP backend) so users keep the credentials they already have.

Define access rules before cutover. This is the step with no equivalent in your current setup, and it's where the migration pays for itself — scope groups to the subnets and services they actually need instead of handing everyone the whole VNet.

Run both in parallel. Leave the gateway up while you move users in waves. Because Access Server is separate infrastructure, you get a genuine parallel-run and rollback path — which the in-place SSTP-to-OpenVPN switch does not give you, since the two cannot coexist on one gateway.

Decommission the gateway's P2S configuration once the last user is moved.

The honest objection: you now own a server

Everything above has a cost, and it is this: you are taking on a VM. Patching, OS upgrades, Access Server upgrades, certificate renewal, monitoring, and HA design all become yours. Azure VPN Gateway is a managed PaaS resource, and giving that up is a real trade, not a rounding error.

Some of it is smaller than it sounds. The Marketplace image handles initial build. Access Server supports multi-node clustering, so HA is a documented pattern rather than a design project. Upgrades are package upgrades. If you already run VMs in Azure — and you almost certainly do — this fits your existing patching and monitoring pipeline rather than adding a new one.

But if your team's honest answer is "we chose the managed gateway because we don't want to run VPN infrastructure," then self-hosting is the wrong direction and you should not talk yourself into it.

That case has a different answer: CloudConnexa, our managed service. You deploy a lightweight Connector into your Azure VNet — available on the Azure Marketplace, or via IPsec if you'd rather terminate a tunnel, and we operate the VPN infrastructure. You get the same per-user access control, the same client platform coverage, and native multi-cloud and multi-site reach, without owning a server. It is the same destination as this article, reached without the operational trade.

Pick based on whether you want control or want it handled. Both beat staying on a gateway whose scaling ceiling is a line item on a SKU chart.

Frequently asked questions

When exactly does Azure SSTP stop working?

March 31, 2027 for existing gateways. New gateways have been unable to enable SSTP since March 31, 2026.

Can I keep SSTP and add another protocol?

Yes, but only IKEv2. Set the tunnel type to "IKEv2 and SSTP" for a no-downtime coexistence period. SSTP and OpenVPN cannot coexist on the same gateway because both are TLS-based.

Why not just switch my gateway to the OpenVPN tunnel type?

It's a legitimate option and it does clear the deadline. It requires downtime and a full client redeployment, and it leaves the gateway's SKU-bound concurrency, Azure-only reach, and route-level policy model unchanged. If the redeployment is happening either way, evaluate both destinations.

Does IKEv2 work everywhere SSTP did?

No. IKEv2 requires UDP 500 and 4500, which are commonly blocked on public and guest Wi-Fi and some carrier networks. SSTP's TCP 443 transport was its main advantage, and OpenVPN protocol — not IKEv2 — is what preserves it.

I'm on the Basic SKU. What are my options now?

Basic gained IKEv2 support in November 2025, and new Basic gateways default to it — so you can flip tunnel type without changing SKU to clear the deadline. What you still don't get on Basic is OpenVPN protocol, RADIUS, BGP, zone redundancy, or Entra ID authentication on P2S. If any of those matter, you're changing SKU or solution regardless.

Will my users keep their existing credentials?

Yes. Access Server authenticates against Microsoft Entra ID via SAML, plus LDAP, RADIUS, PAM, and certificates — so whatever backs your current SSTP deployment carries over.

Can I run Access Server and Azure VPN Gateway at the same time during migration?

Yes, and you should. They're independent, so you can migrate in waves and roll back per-user. That parallel-run path is not available with an in-place SSTP-to-OpenVPN switch.

Should I run Access Server myself, or use CloudConnexa?

Both replace the gateway's SSTP dependency and give you per-user access control instead of route-level policy. Access Server is the self-hosted route — you own the VM, patching, and HA, and get full control over where and how it runs. CloudConnexa is the managed route — you deploy a Connector or IPsec tunnel into your Azure VNet and OpenVPN operates the infrastructure, with native multi-cloud reach built in. Choose based on whether your team wants control or wants it handled, not on which one "works better" — both solve the same underlying problem.

Deploy it and see

The fastest way to evaluate this is to run it in your own subscription alongside your existing gateway. Access Server is on the Azure Marketplace in both pay-as-you-go and bring-your-own-license form — deploy into a test VNet, point a handful of users at it, and compare it against the gateway before you commit to a cutover plan.

Deploy OpenVPN Access Server from the Azure Marketplace (PAYG) → Deploy Access Server (BYOL) → Prefer managed? Deploy the CloudConnexa Azure Connector

You have until March 2027. Deciding in Q4 2026 is a project; deciding in Q1 2027 is an incident.

Sources

• SSTP protocol retirement and connections migration — Microsoft Learn
• About Azure Point-to-Site VPN connections (tunnel-type/auth compatibility) — Microsoft Learn
• About VPN Gateway SKUs (P2S connection limits by SKU) — Microsoft Learn
• Extend Microsoft Azure VPN With OpenVPN Access Server
• Tutorial: Connect Your Azure VNet to CloudConnexa by Deploying a Connector

Further reading

• Access Server Clustering (deep dive)
• Announcing Access Server Pay-As-You-Go for Microsoft Azure
• Access Server Link: a self-hosted VPN for AWS, Azure, and GCP, deployed in minutes
• Zero Trust with Microsoft Entra ID + OpenVPN
• Comparing OpenVPN CloudConnexa and Microsoft Entra