Previously I wrote about Always On VPN options for Microsoft Azure deployments. In that post I indicated that running Windows Server with the Routing and Remote Access Service (RRAS) role for VPN was an option to be considered, even though it is not a formally supported workload. Despite the lack of support by Microsoft, deploying RRAS in Azure works well and is quite popular. In fact, I recently published some configuration guidance for RRAS in Azure.
Load Balancing Options for RRAS
Multiple RRAS servers can be deployed in Azure to provide failover/redundancy or to increase capacity. While Windows Network Load Balancing (NLB) can be used on-premises for RRAS load balancing, NLB is not supported and doesn’t work in Azure. With that, there are several options for load balancing RRAS in Azure. They include DNS round robin, Azure Traffic Manager, the native Azure load balancer, Azure Application Gateway, or a dedicated load balancing virtual appliance.
DNS Round Robin
The easiest way to provide load balancing for RRAS in Azure is to use round robin DNS. However, using this method has some serious limitations. Simple DNS round robin can lead to connection attempts to a server that is offline. In addition, this method doesn’t accurately balance the load and often results in uneven distribution of client connections.
Azure Traffic Manager
Using Azure Traffic Manager is another alternative for load balancing RRAS in Azure. In this scenario each VPN server will have its own public IP address and FQDN for which Azure Traffic Manager will intelligently distribute traffic. Details on configuring Azure Traffic Manager for Always On VPN can be found here.
Azure Load Balancer
The native Azure load balancer can be configured to provide load balancing for RRAS in Azure. However, it has some serious limitations. Consider the following.
- Supports Secure Socket Tunneling Protocol (SSTP) only.
- Basic health check functionality (port probe only).
- Limited visibility.
- Does not work with IKEv2.
- Does not support TLS offload for SSTP.
More information about the Azure Load Balancer can be found here.
Azure Application Gateway
The Azure Application Gateway can be used for load balancing RRAS SSTP VPN connections where advanced capabilities such as enhanced health checks and TLS offload are required. More information about the Azure Application Gateway can be found here.
Load Balancing Appliance
Using a dedicated Application Delivery Controller (ADC), or load balancer is a very effective way to eliminate single points of failure for Always On VPN deployments hosted in Azure. ADCs provide many advanced features and capabilities to ensure full support for all RRAS VPN protocols. In addition, ADCs offer much better visibility and granular control over VPN connections. There are many solutions available as virtual appliances in the Azure marketplace that can be deployed to provide RRAS load balancing in Azure.
Summary
Deploying Windows Server RRAS in Azure for Always On VPN can be a cost-effective solution for many organizations. Although not a formally supported workload, I’ve deployed it numerous times and it works quite well. Consider using a dedicated ADC to increase scalability or provide failover and redundancy for RRAS in Azure whenever possible.
Additional Information
Windows 10 Always On VPN Options for Azure Deployments
Jason Jones
/ October 28, 2019Azure VPN Gateway or Azure Virtual WAN are the preferred way forward here; this is further strengthened by announcements at Ignite soon…
Richard M. Hicks
/ October 28, 2019Other than the supportability for RRAS on Windows Server in Azure, it’s a good solution IMO. Azure VPN gateway and Virtual WAN both have their own challenges which limit their usefulness for Always On VPN deployments. Definitely looking forward to the announcements coming up on Ignite around this though. 🙂
Zack
/ March 12, 2020When using DNS round robin for load balancing with Always On VPN, will the clients disconnect or have issues if they get the alternative IP for the DNS record after the TTL expires? Or will they stay connected to the original server IP?
Richard M. Hicks
/ March 12, 2020It shouldn’t. Once the connection is established it will remain connected to the same server for the duration of the session, regardless if the TTL on the DNS record expires. If the connection drops and the client queries DNS again it might get a different server, but that’s not usually a problem.
Justin
/ May 28, 2020Thanks for another great post Richard! I implemented Azure Traffic Manager after reading this post a while back. It’s working nicely distributing the VPN connections but I’m not able to monitor the servers because I’m using IkeV2 and it doesn’t support UDP monitoring. Do you know of a way to monitor VPN servers using IkeV2 with a Azure based load balancer? I want something that will pickup problems and redistribute the connections if needed. I’ve been thinking of moving to SSTP to solve this, would love to hear your thoughts. Thanks, Justin
Richard M. Hicks
/ May 29, 2020No, there are no options to monitor the IKEv2 service itself using Azure Traffic Manager. Your only option is ICMP (ping), which is obvisouly less than ideal. Your only option would be to use a load balancing appliance like F5 or switch to using SSTP. However, be advised that SSTP monitoring with Azure Traffic Manager is still limited. Azure Traffic Manager doesn’t accept 401 responses as valid, which is the case for SSTP. With that you’ll have to use TCP port check only, which again is still limited. :/
Justin
/ June 1, 2020Thanks Richard, appreciate the feedback. I was planning on switching to Azure Application Gateway with SSTP. Do you think that would be a good fit?
Richard M. Hicks
/ June 4, 2020I’ve never used the Azure application gateway to publish SSTP, but it should work. Just make sure you don’t terminate SSL on the gateway, just forward SSL to the VPN server and it should be fine.