
Organizations migrating on-premises applications, data, and infrastructure to the cloud may also consider terminating Always On VPN connections there. Using one of the native Azure VPN services might be compelling at first glance. After all, having an Azure-managed VPN gateway service sounds intuitive. However, some severe limitations exist for using Azure VPN services for Always On VPN deployments.
Azure VPN Gateway
The following are limitations for Always On VPN with Azure VPN gateway.
Authentication Methods
Azure VPN gateway supports both EAP and machine certificate authentication. However, it can only support one authentication method at a time. With only EAP or certificate authentication, administrators must choose between a device or user tunnel. A single Azure VPN gateway cannot support both at the same time. For native Entra ID joined devices, this is not a problem. However, for native on-premises Active Directory or hybrid Entra ID joined devices, this is a problem, as the device tunnel is essential in these scenarios.
Note: Technically speaking, administrators could deploy another Azure VPN gateway to work around this limitation. However, Azure limits VPN gateway deployments to one per virtual network. This requires administrators to deploy a second VPN gateway in a separate virtual network, which then requires virtual network peering to be enabled, complicating the configuration greatly.
SSTP
Although the Azure VPN gateway supports SSTP, it is, unfortunately, a second-class citizen. Today, all SKUs of the Azure VPN gateway are limited to just 128 SSTP connections (256 in active/active mode). There is currently no way to increase this. If more than 256 connections are required, you must use IKEv2.
RADIUS
In addition, there is currently no option to change the default timeout value (30 seconds) for RADIUS authentication requests. This short timeout value presents a challenge when using MFA with the NPS extension or with Azure Conditional Access, as users may be unable to respond to the push notification before the timeout expires, resulting in failed authentication attempts.
In addition, Azure does not support routing traffic to on-premises RADIUS servers over ExpressRoute connections. In this scenario, administrators must route RADIUS traffic to on-premises servers over a site-to-site connection.
Geographic Redundancy
Geographic redundancy using Azure Traffic Manager (or another global server load balancer) with two or more gateways is not supported when using the Azure VPN gateway. Azure manages the certificate used on the gateway, which includes a certificate with the subject name of the individual gateway. There is no option to supply a custom certificate with a global hostname in the subject, which is required to support geographic redundancy. With that, administrators are limited to the redundancy provided natively by the Azure VPN gateway.
IPv6
Azure does not support Azure VPN gateway in a virtual network that includes IPv6 addressing.
Azure Virtual WAN
Azure Virtual WAN includes many of the same limitations as the Azure VPN gateway, in addition to the following.
SSTP
Unlike the Azure VPN gateway, there is no support for SSTP in Azure Virtual WAN.
IPv6
IPv6 is not currently supported at all in Azure Virtual WAN.
Summary
Intuitively, it seems that leveraging native Azure VPN gateway services would be ideal. However, due to the limitations outlined in this article, administrators must decide carefully if any of these prevent adoption in their environment. Although not formally supported, many organizations deploy Windows Server Routing and Remote Access (RRAS) servers in Azure to address these limitations.
Additional Information
Always On VPN Options for Azure Deployments
Always On VPN with Azure Gateway
Always On VPN Device Tunnel with Azure VPN Gateway






Windows 10 clients include full support for all enterprise DirectAccess scalability and redundancy features, including automatic site selection and transparent failover for multisite deployments. However, the native site selection process is limited in functionality and often yields unexpected results.
To provide geographic redundancy, DirectAccess can be deployed in a multisite configuration. In this scenario, Windows 8.x and Windows 10 clients are aware of all entry points in the enterprise and will automatically select the nearest available entry point to connect to. The nearest entry point is defined as the one that responds the quickest. When a Windows 8.x or Windows 10 client attempts to establish DirectAccess connectivity, an HTTP GET is sent to all entry points and the client will select the one with the shortest Round Trip Time (RTT) for the request.
For the best experience, DirectAccess can be configured to use a Global Server Load Balancing (GSLB) solution to enhance transparent site selection and failover for Windows 8.x and Windows 10 clients. Commonly this is implemented using an on-premises appliance (Citrix NetScaler, F5 Global Traffic Manager, Kemp LoadMaster, A10 Thunder, etc.). These solutions offer exceptional control over DirectAccess traffic distribution, but they add expense and complexity.








