Always On VPN Load Balancing with Loadbalancer.org

Recently, I had the opportunity to deploy the Loadbalancer.org load balancer as part of an enterprise Always On VPN deployment. In the past, I’ve published guidance for using F5 BIG-IP, Citrix ADC (formerly NetScaler), and Kemp LoadMaster, so in this post, I’ll provide guidance for configuring Loadbalancer.org for Always On VPN.

IKEv2

Open the Loadbalancer.org management console and follow the steps below to configure Always On VPN load balancing on the appliance.

Create Virtual Service

Create a layer 4 virtual service for IKEv2.

  1. Click Cluster Configuration.
  2. Click Layer 4 – Virtual Services.
  3. Click Add a new Virtual Service.
  4. Enter a descriptive name for the virtual service in the Label field.
  5. Enter the virtual IP address (VIP) for the service in the IP Address field.
  6. Enter 500,4500 in the Ports field.
  7. Select UDP from the Protocol drop-down list.
  8. Select NAT from the Forwarding Method drop-down list.
  9. Click Update.

Add Real Servers

Add real servers to the virtual service.

  1. Click Layer 4 – Real Servers.
  2. Click Add a new Real Server next to the IKEv2 virtual service.
  3. Enter a descriptive name for the real server in the Label field.
  4. Enter the IP address of the real server in the Real Server IP Address field.
  5. Click Update.
  6. Repeat these steps for each additional VPN server in the cluster.

SSTP

Follow the steps below to configure SSTP load balancing on the appliance.

Create Virtual Service

Create a layer 4 virtual service for SSTP.

  1. Click Cluster Configuration.
  2. Click Layer 4 – Virtual Services.
  3. Click Add a new Virtual Service.
  4. Enter a descriptive name for the virtual service in the Label field.
  5. Enter the virtual IP address (VIP) for the service in the IP Address field.
  6. Enter 443 in the Ports field.
  7. Select TCP from the Protocol drop-down list.
  8. Select NAT from the Forwarding Method drop-down list.
  9. Click Update.

Configure Virtual Service Health Check

Update the health check method for the SSTP virtual service.

  1. Click Layer 4 – Virtual Services.
  2. Click Modify on the SSTP virtual service.
  3. Select Negotiate from the Check Type drop-down list in the Health Checks section.
  4. Enter 443 in the Check Port field.
  5. Select HTTPS from the Protocol drop-down list.
  6. Enter /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ in the Request to send field.
  7. Enter 401 in the Response expected field.
  8. Click Update.

Note: Using the Negotiate health check type for the SSTP monitor on Loadbalancer.org appliances requires version 8.13.0 or later. Administrators can use the External script option when using earlier releases of Loadbalancer.org appliances. An SSTP health check script for Loadbalancer.org can be found here.

Add Real Servers

Add real servers to the virtual service.

  1. Click Layer 4 – Real Servers.
  2. Click Add a new Real Server next to the SSTP virtual service.
  3. Enter a descriptive name for the real server in the Label field.
  4. Enter the IP address of the real server in the Real Server IP Address field.
  5. Click Update.
  6. Repeat these steps for each additional VPN server in the cluster.

Review

Once complete, click System Overview to view the overall health of your VPN servers.

Summary

The Loadbalancer.org appliance is an efficient, cost-effective, and easy-to-configure load-balancing solution that works well with Always On VPN implementations. It’s available as a physical or virtual appliance. There’s also a cloud-based version. It also includes advanced features such as TLS offload, web application firewall (WAF), global server load balancing (GSLB), and more. If you are looking for a layer 4-7 load balancer for Always On VPN and other workloads, be sure to check them out.

Additional Information

Loadbalancer.org Virtual Appliance

SSTP Health Check Script for Loadbalancer.org

Mastering Certificates with Intune Training Course

I’m excited to announce I’ll present a three-day LIVE online training event covering all things Microsoft Intune and certificates. This training event takes place on the ViaMonstra online academy January 28-30, 2025.

Course Material

This training course comprehensively examines all aspects of delivering certificates using Microsoft Intune, including common deployment scenarios, PKCS and SCEP configuration, Intune certificate connector configuration, high availability strategies, implementation and security best practices, and troubleshooting.

Cloud PKI

Cloud PKI, a new cloud-based PKI-as-a-Service solution from Microsoft, will also be covered in depth. I’ll provide an overview of the service and discuss the advantages and limitations of Cloud PKI. We’ll also cover different configuration and deployment scenarios, including Bring Your Own CA (BYOCA). In addition, I’ll share security best practices for Microsoft Cloud PKI deployments.

Register Now

Space is limited, so don’t miss out on this excellent opportunity to learn about these critically essential technologies. Reserve your spot in this training class today!

Additional Information

Mastering Certificates and Microsoft Intune

Microsoft Cloud PKI

ViaMonstra Online Academy

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

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

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?