All posts tagged Remote Access

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

Leave a comment
by Richard M. Hicks on January 26, 2026  •  Permalink
Posted in administration, Always On VPN, AOVPN, Azure, Azure VPN, Azure VPN Gateway, cloud, Deployment, device tunnel, end of life, Enterprise, enterprise mobility, IKEv2, Infrastructure, Microsoft, Mobility, OpenVPN, public cloud, Remote Access, routing and remote access service, RRAS, Secure Socket Tunneling Protocol, Security, SSTP, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 26, 2026

https://directaccess.richardhicks.com/2026/01/26/always-on-vpn-and-azure-vpn-gateway-sstp-protocol-retirement/

Always On VPN Servers and Failover

When configuring Microsoft Always On VPN, one of the first and most crucial settings is defining the public hostname of the VPN server to which clients connect. If you’re deploying Always On VPN client configuration settings using Intune—either with the native VPN policy template or a custom XML profile—you’ll see that multiple server entries are supported. Intune even allows administrators to define a “default server.” At first glance, this might suggest that the client will try the default server first and automatically fail over to the others if it’s unavailable. Unfortunately, that’s not how it works.

Intune VPN Template

When using the native Intune VPN device configuration template, administrators will find multiple entry fields for the servers in the Base VPN section.

In the example below, the Global VPN entry is marked as ‘default’.

Custom XML

When defining VPN settings using XML configuration, administrators can also list multiple servers.

Interestingly, the VPNv2 CSP used by custom XML profiles doesn’t support the concept of a “default server” at all.

How It Really Works

Defining multiple servers in the Always On VPN profile does not enable automatic failover. The client connects only to the first server in the list. The so-called “default server” setting in Intune is ignored, and the GUI even allows you to mark all servers as default, which is meaningless.

However, the configuration isn’t entirely useless. If you define multiple servers, they’ll appear on the client side as manual options. If the first server becomes unavailable, the user can open the Settings app, navigate to the advanced settings of the Always On VPN profile, and select an alternate server to connect manually.

Summary

Although Intune and XML configurations allow multiple VPN servers, Always On VPN does not provide automatic failover. Clients only attempt to connect to the first server in the list, and the “default server” setting in Intune has no effect. Multiple entries are still useful, but only for manual server selection by end-users when the primary server is down. For true automated high availability and redundancy, consider an external solution such as Azure Traffic Manager.

Additional Information

Always On VPN Multisite with Azure Traffic Manager

1 Comment
by Richard M. Hicks on September 8, 2025  •  Permalink
Posted in administration, Always On VPN, AOVPN, Azure Traffic Manager, Deployment, Device Management, device tunnel, Enterprise, enterprise mobility, Geographic Redundnacy, global server load balancer, High Availability, InTune, Load Balancing, Microsoft, Microsoft Intune, Mobile Device Management, Mobility, OMA-DM, OMA-URI, Operational Support, ProfileXML, Remote Access, System Center Configuration Manager, systems management, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on September 8, 2025

https://directaccess.richardhicks.com/2025/09/08/always-on-vpn-servers-and-failover/

Always On VPN Security Updates June 2025

Patch Tuesday is upon us again; thankfully, it’s a light month of Always On VPN administrators. The Microsoft monthly security updates for June 2025 include just a few Windows Routing and Remote Access Service (RRAS) fixes. In addition, an update is available for a vulnerability in the Windows Remote Access Connection Manager. Significantly, DirectAccess administrators are affected this month by a vulnerability identified in the Windows KDC Proxy Service (KPSSVC).

RRAS Updates

The Microsoft security updates for June 2025 address the following CVEs for Windows Server RRAS.

Both RRAS CVEs are Remote Code Execution (RCE) vulnerabilities with max severity ratings of Important.

Remote Access Connection Manager

A security vulnerability in the Windows Remote Access Connection Manager is addressed with the following CVE.

An attacker exploiting this vulnerability could elevate local access privileges.

KDC Proxy

This critical vulnerability affects those organizations still supporting Microsoft DirectAccess in their environments.

This CVE addresses an RCE in the KDC Proxy Service (KPSSVC) that could allow an attacker to execute arbitrary code over the network. DirectAccess administrators are encouraged to apply this update as soon as possible.

Additional Information

Microsoft June 2025 Security Updates

Leave a comment
by Richard M. Hicks on June 10, 2025  •  Permalink
Posted in authentication, KDC Proxy, Microsoft, Remote Access, routing and remote access service, RRAS, Security Update, Update, Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 10, 2025

https://directaccess.richardhicks.com/2025/06/10/always-on-vpn-security-updates-june-2025/

« Older Posts
Newer Posts »