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

DirectAccess and CVE-2024-38063

With the August 2024 Windows security updates, Microsoft released a fix to address a Remote Code Execution vulnerability in the Windows TCP/IP stack (CVE-2024-38063). Critically, this vulnerability affects IPv6 only and does not require authentication or user interaction to exploit. An attacker would only need to send specially crafted IPv6 packets to a Windows host, which could allow them to run arbitrary code on the server. This vulnerability presents some unique challenges for organizations that have deployed DirectAccess.

Exposure

DirectAccess servers are deployed to provide secure remote access and are, necessarily, exposed to the public Internet. Sometimes, this is a direct connection (not recommended) or behind an edge firewall or load balancer. In either case, anyone can establish a TCP connection from the Internet to the DirectAccess server by default. If the DirectAccess server has a global unicast IPv6 address assigned to its external interface, that presents a worst-case scenario for exposure. Administrators should update their DirectAccess servers immediately. There are some other mitigation options, though. See below for more details.

IPv6 Transition

DirectAccess servers are usually reachable on the public Internet via IPv4 only. The lack of direct IPv6 connectivity significantly reduces the attack vector for this vulnerability. However, DirectAccess servers use various IPv6 transition technologies that could present additional risks.

Tunnel Establishment

Clients on the Internet can establish an IPv6 transition tunnel to the DirectAccess server without authentication. Once the tunnel is established, the client will receive a router advertisement (RA) and establish an IPv6 address on link. However, communication over the link requires IPsec. Although an attacker can obtain an IPv6 address, they require authentication to send TCP and UDP traffic inside the tunnel.

ICMP

It’s important to know that ICMP traffic inside the DirectAccess IPv6 transition tunnel is exempt from IPsec policy processing, by default. It is unclear whether the “specially crafted packets” an attacker must send to exploit this vulnerability can be ICMP packets. If that’s the case, this introduces significant risks and increases exposure exponentially. I will update this post if I learn anything more about this specifically.

Mitigation

The best and most obvious way to mitigate this attack is to immediately apply the Microsoft security updates. However, some additional controls can be effective in mitigating this risk.

Authentication

As mentioned, DirectAccess allows IPv6 transition tunnels to be established by default without authentication. However, it is possible to update the DirectAccess configuration to support authentication, as described here.

https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/

Note: Updating the DirectAccess configuration can be impactful for remote users. Be sure to test this change in a lab environment before implementing in production.

Load Balancers

If the DirectAccess server is behind a load balancer, it can be configured to require authentication for DirectAccess IPv6 transition tunnels. Below is published guidance for configuring popular load balancers to support this.

F5 BIG-IP

Citrix ADC (formerly NetScaler)

Additional Information

Microsoft Windows TCP/IP Remote Code Execution Vulnerability

DirectAccess IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

DirectAccess IP-HTTPS Preauthentication using Citrix ADC (formerly NetScaler)

Always On VPN July 2023 Security Updates

Hello, Always On VPN administrators! It’s the second Tuesday of the month, so you know what that means. Yes, it’s Patch Tuesday! This month’s security updates include several fixes for vulnerabilities potentially affecting Microsoft Always On VPN deployments.

RRAS Vulnerabilities

Microsoft’s July 2023 security updates include fixes affecting Windows Servers with the Routing and Remote Access Service (RRAS) role installed. Security vulnerabilities CVE-2023-35365, CVE-2023-35366, and CVE-2023-35367 are all Remote Code Execution (RCE) vulnerabilities with a Critical security rating and a CVSS score of 9.8. These security vulnerabilities in Windows Server RRAS are particularly troublesome due to the nature of the workload. RRAS servers are, by design, exposed to the public Internet. Although there are no known exploits in the wild at this time, this attack requires no special privileges other than network access. Administrators running Windows Server with RRAS installed are encouraged to update as soon as possible.

AD CS Vulnerabilities

Most Always On VPN implementations leverage enterprise PKI certificates for user and device authentication. Administrators commonly deploy Microsoft Active Directory Certificate Services (AD CS) to support this. This month there are two security vulnerabilities in AD CS marked as Important. CVE-2023-35350 and CVE-2023-35351 address RCE vulnerabilities that exploit a race condition on the server. However, AD CS servers are not exposed to untrusted networks. In addition, attackers would require administrative rights on the server to exploit these vulnerabilities.

Network Load Balancing

Finally, of importance to Always On VPN administrators using Windows Network Load Balancing (NLB) to provide load balancing for their RRAS servers, there is a vulnerability in the NLB service. CVE-2023-33163 addresses an RCE vulnerability in NLB identified as Important.

Additional Information

Microsoft July 2023 Security Updates

Windows Server 2022 KB5028171 (Build 20348.1850)

Windows Server 2019 KB5028168 (Build 17763.4645)

Windows Server 2016 KB 5028169 (Build 14393.6085)

Windows 11 22H2 KB8028185 (Build 22621.1992)

Windows 11 21H2 KB5028182 (Build 22000.2176)