Always On VPN Servers and Failover

When configuring Microsoft Always On VPN, one of the first and most crucial settings is defining the public hostname of the VPN server to which clients connect. If you’re deploying Always On VPN client configuration settings using Intune—either with the native VPN policy template or a custom XML profile—you’ll see that multiple server entries are supported. Intune even allows administrators to define a “default server.” At first glance, this might suggest that the client will try the default server first and automatically fail over to the others if it’s unavailable. Unfortunately, that’s not how it works.

Intune VPN Template

When using the native Intune VPN device configuration template, administrators will find multiple entry fields for the servers in the Base VPN section.

In the example below, the Global VPN entry is marked as ‘default’.

Custom XML

When defining VPN settings using XML configuration, administrators can also list multiple servers.

Interestingly, the VPNv2 CSP used by custom XML profiles doesn’t support the concept of a “default server” at all.

How It Really Works

Defining multiple servers in the Always On VPN profile does not enable automatic failover. The client connects only to the first server in the list. The so-called “default server” setting in Intune is ignored, and the GUI even allows you to mark all servers as default, which is meaningless.

However, the configuration isn’t entirely useless. If you define multiple servers, they’ll appear on the client side as manual options. If the first server becomes unavailable, the user can open the Settings app, navigate to the advanced settings of the Always On VPN profile, and select an alternate server to connect manually.

Summary

Although Intune and XML configurations allow multiple VPN servers, Always On VPN does not provide automatic failover. Clients only attempt to connect to the first server in the list, and the “default server” setting in Intune has no effect. Multiple entries are still useful, but only for manual server selection by end-users when the primary server is down. For true automated high availability and redundancy, consider an external solution such as Azure Traffic Manager.

Additional Information

Always On VPN Multisite with Azure Traffic Manager

Always On VPN Security Updates June 2025

Patch Tuesday is upon us again; thankfully, it’s a light month of Always On VPN administrators. The Microsoft monthly security updates for June 2025 include just a few Windows Routing and Remote Access Service (RRAS) fixes. In addition, an update is available for a vulnerability in the Windows Remote Access Connection Manager. Significantly, DirectAccess administrators are affected this month by a vulnerability identified in the Windows KDC Proxy Service (KPSSVC).

RRAS Updates

The Microsoft security updates for June 2025 address the following CVEs for Windows Server RRAS.

Both RRAS CVEs are Remote Code Execution (RCE) vulnerabilities with max severity ratings of Important.

Remote Access Connection Manager

A security vulnerability in the Windows Remote Access Connection Manager is addressed with the following CVE.

An attacker exploiting this vulnerability could elevate local access privileges.

KDC Proxy

This critical vulnerability affects those organizations still supporting Microsoft DirectAccess in their environments.

This CVE addresses an RCE in the KDC Proxy Service (KPSSVC) that could allow an attacker to execute arbitrary code over the network. DirectAccess administrators are encouraged to apply this update as soon as possible.

Additional Information

Microsoft June 2025 Security Updates

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