Entra Internet Access TLS Inspection and Always On VPN: Troubleshooting SSTP Connection Failures

Microsoft Entra Global Secure Access (GSA) is a cloud-based Security Service Edge (SSE) solution that includes Entra Private Access to provide zero-trust network access to private data and applications, and Entra Internet Access to provide security controls for general internet access. Entra Internet Access includes features such as web content filtering, AI prompt controls, TLS inspection, and more. Entra Private Access and Entra Internet Access share a common client: the Global Secure Access Client.

TLS Inspection

TLS inspection is a powerful feature of Entra Internet Access that allows inspection and policy enforcement for encrypted internet traffic. It enables more thorough inspection and is required for features such as AI prompt policies. When TLS inspection is enabled, the TLS connection from the target server (origin server) is terminated by the Entra service. A new session is created between the cloud and the endpoint using a dynamically generated TLS certificate issued by Entra. As Entra holds the private key for this certificate, it can decrypt and inspect traffic as necessary.

Always On VPN

Recently, a customer asked me to help troubleshoot an Always On VPN user tunnel connectivity issue. The problem began shortly after deploying the Global Secure Access client with TLS inspection enabled. Administrators had configured the default TLS inspection policy to inspect traffic for all websites.

User Tunnel Failures

Attempts to manually start the Always On VPN user tunnel resulted in a failed connection attempt with the following error message.

Error 0x800704D4: The network connection was aborted by the local system.

Event Logs

Reviewing the client event logs revealed numerous Event ID 20227 entries from the RasClient source with the following error message.

The user DOMAIN\User dialed a connection named [connection name] which has failed. The error code returned on failure is -2147023660.

Note: Error code -2147023660 is the decimal equivalent of 0x800704D4.

Troubleshooting

Initial testing with Test-NetConnection confirmed that TCP port 443 on the VPN server was reachable. However, using Get-TlsCertificate revealed the real problem.

Although the certificate subject matched the VPN server, the issuer did not. Instead of the VPN server’s issuing CA, the certificate had been issued by Microsoft Entra Global Secure Access, confirming that TLS inspection was intercepting the connection.

SSTP and TLS Inspection

The Secure Socket Tunneling Protocol (SSTP) is a Microsoft proprietary VPN transport that uses HTTP for tunneling and TLS for security. Unlike a web browser, which can establish a new trusted TLS session with an inspection proxy, SSTP validates the VPN server’s certificate as part of establishing the VPN tunnel. Any certificate substitution, even by a trusted TLS inspection service, changes the server certificate thumbprint and causes SSTP validation to fail.

Workaround

The solution is to create a TLS inspection exclusion policy to exempt inspection for the VPN server FQDN(s), as shown here.

Summary

Microsoft Entra Internet Access TLS inspection can unintentionally interfere with Always On VPN deployments that use SSTP. Because TLS inspection replaces the VPN server’s certificate with one issued by Microsoft Entra, SSTP detects the certificate mismatch and terminates the connection. If you use Always On VPN with Entra Internet Access, configure a TLS inspection exclusion for your VPN server FQDNs to prevent interception while preserving TLS inspection for general internet traffic.

Additional Information

Always On VPN vs. Entra Private Access: Choosing the Right Access Model for your Organization

What is Microsoft Entra Global Secure Access?

Microsoft Entra Internet Access

Microsoft Entra Private Access

Always On VPN SSTP and 47-Day TLS Certificates

Always On VPN SSTP and HSTS

Always On VPN Ask Me Anything (AMA) April 2026

We’re already through most of Q1 2026, so I’ve put another AMA on the calendar so we can all connect again. Be sure to join me on Tuesday, April 7, at 10:00 AM PDT (UTC -7) for the next edition of the Always On VPN AMA (Ask Me Anything!) session.

Do you have questions about Always On VPN? Are you having a specific issue you can’t figure out? Would you like more information about configuration options? Here’s your chance to get your questions answered! Register now and join the session to ask me anything (AMA!) about Microsoft Windows Always On VPN and related technologies.

The AMA will be an open forum session where we can all talk shop about Always On VPN and related technologies. It’s a great chance to learn new things and share experiences with your peers. We’ll discuss known issues and limitations, best practices, and more. I’m also planning to have some special guests, so be sure to join us!

Everyone is welcome. Don’t miss out on this excellent opportunity to connect and learn. Register now!

Can’t make the session? Register anyway, and I’ll send you the link to the recording as soon as it is available!

Always On VPN and Azure VPN Gateway SSTP Protocol Retirement

The Azure VPN gateway has been an option for supporting Microsoft Always On VPN client connections for organizations moving resources to the cloud. Today, Azure VPN gateway supports Internet Key Exchange version 2 (IKEv2), OpenVPN, and Secure Socket Tunneling Protocol (SSTP), although SSTP support has long been limited in scope and scalability. However, Microsoft recently indicated that some important changes are coming soon that will affect VPN protocol support on the Azure VPN gateway.

SSTP and Azure VPN Gateway

Microsoft has announced plans to deprecate and eventually remove support for SSTP on the Azure VPN gateway.

Key Dates

Here is Microsoft’s timeline for retiring SSTP for VPN connections.

  • March 31, 2026 – SSTP can no longer be enabled on new or existing gateways
  • March 31, 2027 – Existing SSTP connections will stop functioning

SSTP: Second Class Citizen

The retirement of SSTP for Azure VPN gateway should not have a significant impact on Always On VPN deployments. Support for SSTP on Azure VPN gateway has always been limited, making it a less viable option for most Always On VPN deployments. SSTP connections are capped at 128 concurrent connections (256 in active-active mode), regardless of gateway SKU. Additionally, Azure VPN gateway does not support simultaneous user and device tunnels, further limiting its usefulness in modern Always On VPN designs.

Plan Migration Now

If you are using Azure VPN gateway to support Always On VPN client connections, now is the time to begin planning a migration to IKEv2, which offers better scalability and native Always On VPN support. Alternatively, consider Windows Server RRAS in Azure, a third-party VPN solution, or Entra Private Access if Azure VPN gateway no longer meets your requirements.

More Information

For official guidance, see SSTP Protocol Retirement and Connections Migration. If you’re unsure how this change affects your Always On VPN deployment, or you would like help planning a migration, this is a good time to review your design and roadmap. Fill out the form below, and I’ll provide you with more information.

Additional Information

SSTP Protocol Retirement and Connections Migration

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

Windows Server RRAS in Microsoft Azure

Microsoft Entra Private Access