DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

DirectAccess Deployment Guide for Kemp LoadMaster Load BalancersA few months ago I had the opportunity to work with the folks at KEMP Technologies to document the use of their LoadMaster load balancers for Windows Server 2012 R2 DirectAccess deployments. DirectAccess has several critical single points of failure which can benefit from the use of a load balancer. Typically Windows Network Load Balancing (NLB) is used in these scenarios, but NLB suffers from some serious limitations and lacks essential capabilities required to fully address these requirements. The use of an external third-party load balancer can provide better load distribution and more granular traffic control, while at the same time improving availability with intelligent service health checks.

Working with the LoadMaster was a great experience. Installation was quick and simple, and their web-based management console is intuitive and easy to use. The LoadMaster includes essential features that are required for load balancing DirectAccess servers, and advanced capabilities that can be leveraged to enhance geographic redundancy for multisite deployments.

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

KEMP offers the widest platform coverage with their solutions, including dedicated hardware appliances, virtual appliances for multiple hypervisors including Hyper-V, cloud-based including Microsoft Azure, as well as bare metal support for installation on your own hardware. You can download a fully functional free trial here.

You can view and download the Windows Server 2012 R2 DirectAccess Deployment Guide for the KEMP LoadMaster load balancing solution here.

Additional Resources

Video: Enable Load Balancing for DirectAccess

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

DirectAccess Single NIC Load Balancing with KEMP LoadMaster Load Balancers

DirectAccess and the Free KEMP LoadMaster Load Balancer

Webinar Recording: DirectAccess Load Balancing Tips and Tricks

Webinar Recording: DirectAccess Multisite with Windows 10 and KEMP LoadMaster GEO

Webinar Recording: Maximize Your Investment in Windows 10 with DirectAccess and the KEMP LoadMaster Load Balancer

Implementing DirectAccess with Windows Server 2016 book


Disable 6to4 IPv6 Transition Protocol for DirectAccess Clients


DirectAccess client to server connections are established exclusively over IPv6. To allow for this communication to take place over the public IPv4 Internet, DirectAccess uses IPv6 transition protocols – 6to4, Teredo, and IP-HTTPS – to tunnel IPv6 communication over IPv4. 6to4 is supported when the DirectAccess server is edge facing with a public IPv4 address assigned to its external network interface. Two consecutive public IPv4 addresses are required to support Teredo. IP-HTTPS is used in all scenarios, and exclusively when the DirectAccess server is located in a perimeter or DMZ network behind a NAT device.

6to4 and Teredo Advantages

Not all IPv6 transition protocols are created equal. For Windows 7 clients, 6to4 and Teredo provide significant performance advantages when compared to IP-HTTPS (Windows 8.x clients can use null encryption for IP-HTTPS, which eliminates this performance advantage). 6to4 and Teredo offer nearly identical performance, but 6to4 suffers from some unique challenges and should be disabled by default for all DirectAccess deployments.

Note: IP-HTTPS null encryption is disabled for all clients when client-based remote access VPN or one-time password (OTP) authentication is configured on the DirectAccess server, which can impact performance for Windows 8.x clients using IP-HTTPS.

Unreliable Fallback

The 6to4 IPv6 transition protocol is used when a DirectAccess client has a public IPv4 address assigned to its network interface. 6to4 uses IP protocol 41 for transport, and does not work when the client is behind a NAT. If outbound IP protocol 41 is blocked (a common scenario) then the client should fallback to Teredo or IP-HTTPS. In my experience this doesn’t always happen. In fact, the protocol fallback fails with enough regularity that it is the primary reason I recommend disabling it by default.

Active Directory IP Subnet Assignment

6to4 is also problematic when it comes to configuring Active Directory IP subnets for clients in a multisite DirectAccess deployment. 6to4 addresses begin with the 2002::/16 prefix followed by the IPv4 address of the client represented in hexadecimal using the form WWXX:YYZZ::WWXX:YYZZ. For example, if the DirectAccess client’s public IPv4 address is, its 6to4 address would be 2002:c633:6453::c633:6453. Since this IPv6 address is created using only the client’s IPv4 address, there is no way to associate the client to a specific entry point. The administrator is left with assigning the 2002::/16 prefix to the most centrally located AD site. This will undoubtedly result in some DirectAccess clients using domain controllers that are not ideal, which will ultimately lead to slow log on times and mapped drive failures.


In some deployment scenarios, 6to4 and Teredo offer performance advantages when compared to IP-HTTPS. Performance is identical for both 6to4 and Teredo, and considering the challenges that 6to4 poses, it should be disabled by default for DirectAccess deployments. This eliminates the possibility of associated connectivity issues, while still allowing DirectAccess clients to use the Teredo IPv6 transition protocol and not incur any performance penalty. Details about disabling IPv6 transition protocols can be found here.

%d bloggers like this: