All posts tagged SSTP

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

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

Always On VPN and RRAS in Azure

What is Azure VPN Gateway?

What is Azure Virtual WAN?

Always On VPN and VpnStrategy

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Always On VPN supports a variety of VPN protocols for the user tunnel. Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP) are the most common. I wrote about the advantages and disadvantages of each in this post. To summarize, IKEv2 provides the highest security options but suffers from operational limitations. SSTP offers excellent security and is generally more reliable.

VpnStrategy

Always On VPN administrators must choose between IKEv2 and SSTP when configuring the Always On VPN user tunnel. Some administrators may prefer to use IKEv2 when available but then fall back to SSTP if it is not. To accomplish this requires editing the rasphone.pbk file and setting the value of VpnStrategy to 8, as described here.

Challenges

Unfortunately, setting the VpnStrategy value to 8 poses some challenges. Updating rasphone.pbk requires editing a text file on each endpoint post-deployment. Updating rasphone.pbk can be automated using the Update-Rasphone.ps1 script or Microsoft Intune proactive remediation.

Limitations

By default, Windows will overwrite the VpnStrategy setting in rasphone.pbk when fallback occurs. For example, setting VpnStrategy to prefer IKEv2 over SSTP will be reset to use SSTP first if a connection with IKEv2 fails. There’s a registry setting available that’s supposed to prevent this, but it doesn’t always work as expected.

Windows 11

There’s good news for administrators deploying Always On VPN on Windows 11. Microsoft recently introduced support for additional NativeProtocol types in XML. Specifically, VPN protocol preference can now be defined using the ProtocolList native protocol type. When using the ProtocolList native protocol type, each supported VPN protocol is listed in order of preference using the syntax shown below.

In addition, the RetryTimeInHours value defines the time Windows will try the last successful connection protocol. Setting this value to 0 overrides this and ensures the preferred protocol (the first protocol in the list) will always be attempted first.

SSTP Only

Previously the VPNv2CSP only supported IKEv2 or Automatic as values for the native protocol type. Windows 11 now supports SSTP as a native protocol type. Administrators configuring Always On VPN user tunnel connections using SSTP exclusively can now use this option.

Caveats

While the settings above are supported in both Windows 11 21H2 and 22H2, there are some known issues when enabling these settings. Specifically, when administrators define the ProtocolList value for the native protocol type, IKEv2 is always shown as the active protocol, even when an SSTP connection is established.

Also, if ProtocolList is used, the VPN connection cannot be managed using PowerShell. The VPN profile will not be displayed when running Get-VpnConnection at the time of this writing. Hopefully Microsoft will fix this soon.