
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.
- Click Cluster Configuration.
- Click Layer 4 – Virtual Services.
- Click Add a new Virtual Service.
- Enter a descriptive name for the virtual service in the Label field.
- Enter the virtual IP address (VIP) for the service in the IP Address field.
- Enter 500,4500 in the Ports field.
- Select UDP from the Protocol drop-down list.
- Select NAT from the Forwarding Method drop-down list.
- Click Update.

Add Real Servers
Add real servers to the virtual service.
- Click Layer 4 – Real Servers.
- Click Add a new Real Server next to the IKEv2 virtual service.
- Enter a descriptive name for the real server in the Label field.
- Enter the IP address of the real server in the Real Server IP Address field.
- Click Update.
- 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.
- Click Cluster Configuration.
- Click Layer 4 – Virtual Services.
- Click Add a new Virtual Service.
- Enter a descriptive name for the virtual service in the Label field.
- Enter the virtual IP address (VIP) for the service in the IP Address field.
- Enter 443 in the Ports field.
- Select TCP from the Protocol drop-down list.
- Select NAT from the Forwarding Method drop-down list.
- Click Update.
Configure Virtual Service Health Check
Update the health check method for the SSTP virtual service.
- Click Layer 4 – Virtual Services.
- Click Modify on the SSTP virtual service.
- Select Negotiate from the Check Type drop-down list in the Health Checks section.
- Enter 443 in the Check Port field.
- Select HTTPS from the Protocol drop-down list.
- Enter /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ in the Request to send field.
- Enter 401 in the Response expected field.
- 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.
- Click Layer 4 – Real Servers.
- Click Add a new Real Server next to the SSTP virtual service.
- Enter a descriptive name for the real server in the Label field.
- Enter the IP address of the real server in the Real Server IP Address field.
- Click Update.
- 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.
Stefaan Pouseele
/ March 13, 2025I think there is a typo in the SSTP Create Virtual Service step 7: the protocol should be TCP instead of UDP.
Richard M. Hicks
/ March 13, 2025Thanks, Stefaan! Corrected. 🙂
Ed Morgan
/ March 17, 2025We use SNAT as it didn’t require the real servers to have their default route changed.
Also a very very persistence long timeout of several hours. This is because we were getting a device tunnel connected to one real server and the user tunnel connected to another. The clients did not like this at all, many strange network issues resulted.
Richard M. Hicks
/ March 17, 2025The drawback to using SNAT is that all requests appear to come from the load balancer, making the log files less useful. There are some other related issues as well. Glad to hear it’s working well for you though! It really is a great solution.