Configure F5 BIG-IP for DirectAccess NLS

Recently I wrote about the Network Location Server (NLS) and its importance for DirectAccess deployments. As I described previously, the NLS is nothing more than a web server with an SSL certificate installed. It should also be made highly available to prevent potential service disruption caused by planned or unplanned NLS server downtime. Any web server can serve as the NLS. In addition, if you have the F5 BIG-IP Local Traffic Manager (LTM) in your environment, you can easily configure the LTM to serve as the NLS.

To accomplish this, import the SSL certificate for the NLS and create an SSL client profile using its certificate and private key. Next, create a new iRule that contains the following code.

HTTP::respond 200 

Configure F5 BGIP for DirectAccess NLS

Finally, create a new virtual server listening on TCP port 443 and assign this iRule as a resource for the virtual server. Once NLS reachability has been verified, update the DirectAccess configuration using the Remote Access Management console or the Set-DANetworkLocationServer PowerShell cmdlet.

TechMentor 2015 DirectAccess Deep Dive Training Session

I’m excited to announce that I’ll once again be participating in this year’s TechMentor conference in Redmond, WA! The event takes place August 3-7, 2015 and will be held on the Microsoft campus in building 33. This is a great event at an incredible venue! I’ll be delivering a 3 hour Windows Server 2012 R2 DirectAccess deep drive technical training session on Thursday, August 6. The conference covers a wide range of topics from many noted industry experts like Don Jones, Greg Shields, Jeff Hicks, Orin Thomas, and many more. Don’t miss out. Register today and use priority code TMRSK05 to save $500!

TechMentor Conference 2014

DirectAccess Network Location Server Guidance


The Network Location Server (NLS) is a critical component in a DirectAccess deployment. The NLS is used by DirectAccess clients to determine if they are inside or outside of the corporate network. If a DirectAccess client can connect to the NLS, it must be inside the corporate network. If it cannot, it must be outside of the corporate network. It is for this reason that the NLS must not be reachable from the public Internet. A client configured for DirectAccess will probe the NLS when it first starts, and on subsequent network interface status changes.

What is the NLS?

The NLS itself is nothing more than a web server with an SSL certificate installed. Beginning with Windows Server 2012, the NLS can be collocated on the DirectAccess server itself. Although there may be scenarios in which this is acceptable, it is generally recommended that NLS be configured on a server dedicated to this role.

NLS Configuration

Any web server can be used, including IIS, Apache, Nginx, Lighttpd, and others. You can also use an Application Delivery Controller (ADC) like the F5 BIG-IP Local Traffic Manager (LTM), as described here. The web server must have a valid SSL certificate installed that includes a subject name that matches the NLS FQDN (e.g. The DNS record for the NLS must configured using an A host record. A CNAME DNS entry will not work. In addition, the NLS must also respond to ICMP echo requests.

DirectAccess Network Location Server Guidance

DirectAccess Network Location Server Guidance

The certificate can be issued by an internal PKI or a public third-party Certificate Authority (CA). A self-signed certificate can be used if the certificate is distributed to all DirectAccess clients and servers, but this is not advisable. To avoid possible service disruptions, the NLS should be made highly available by deploying at least two NLS in a load balanced configuration.

What Happens if the NLS is Offline?

If the NLS is offline for any reason, remote DirectAccess clients will be unaffected. However, DirectAccess clients on the internal network will mistakenly believe they are outside of the corporate network and attempt to establish a DirectAccess connection. If the DirectAccess server is not accessible from the internal network, the client will be unable to connect to any local network resources by name until the NLS is brought online or other actions are taken.

Collocation Issues

As mentioned previously, it is possible in some scenarios to collocate the NLS on the DirectAccess server. This is probably acceptable for proof-of-concept deployments, but any production deployment should have the NLS configured on a server dedicated to this role. If the NLS is located on the DirectAccess server and the server is offline for any reason, DirectAccess clients on the internal network will be unable to access local resources by name until the DirectAccess server is back online.

Don’t Use Existing Web Application Servers

Occasionally I will encounter a scenario in which an administrator who wants to avoid implementing additional infrastructure will use an existing internal web application server for the NLS, such as a SharePoint server. Although this will work, it quickly becomes an issue when remote DirectAccess clients need to access the server. Since the NLS is not resolvable or reachable externally, connectivity will fail, preventing DirectAccess clients from reaching the internal application.


The NLS is a vitally important piece of the DirectAccess architecture. DirectAccess clients use the NLS to determine their location, and if the service is unavailable for any reason (planned or unplanned) internal DirectAccess clients will be negatively affected. The NLS isn’t necessarily complicated, as it is nothing more than a web server with an SSL certificate installed. However, don’t overlook the importance of this service, and make sure it is highly available to avoid any potential network connectivity issues.

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: