DirectAccess Network Location Server Guidance

Introduction

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. nls.corp.example.com). 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.

Summary

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.

Additional Resources

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

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

Configure Citrix NetScaler for DirectAccess Network Location Server (NLS)

Configure F5 BIG-IP for DirectAccess Network Location Server (NLS) 

DirectAccess Clients in Connecting State when using External Load Balancer

After configuring a Windows Server 2012/R2 DirectAccess server to use an external load balancer, the network connectivity status indicator on the DirectAccess client may perpetually indicate a connecting state.

DirectAccess Clients in Connecting State when using External Load Balancer

In addition, the Get-DAConnectionStatus PowerShell cmdlet returns the following error:

Status : Error
Substatus : RemoteNetworkAuthenticationFailure

DirectAccess Clients in Connecting State when using External Load Balancer

In spite of what the network connectivity status indicator reports, DirectAccess clients are connected and can successfully connect to corporate network resources via DirectAccess.

DirectAccess Clients in Connecting State when using External Load Balancer

To verify that resources on the corporate network are reachable after the DirectAccess session is established, a DirectAccess client makes an HTTP request to the host directaccess-WebProbeHost. This hostname resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. However, when an external load balancer is configured, the original dedicated IP address (DIP) of the first DirectAccess server becomes the new virtual IP address (VIP) of the cluster, which now resides on the load balancer. After configuring an external load balancer, the DNS record for directaccess-WebProbeHost now resolves to the virtual IP address (VIP) of the cluster, and if this VIP isn’t configured to deliver HTTP requests to the DirectAccess servers, the client-side connectivity check fails.

DirectAccess Clients in Connecting State when using External Load Balancer

To resolve this issue it is necessary to also create a virtual server on the load balancer with the internal IPv4 address that directaccess-WebProbeHost resolves to. The service port should be configured for HTTP (TCP port 80) and can use the same pool used by the external virtual server.

DirectAccess Clients in Connecting State when using External Load Balancer

Once this virtual server is configured, the network connectivity status indicator for DirectAccess will now accurately reflect that it is connected via DirectAccess.

DirectAccess Clients in Connecting State when using External Load Balancer

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

An important scalability improvement introduced in Windows Server 2012 DirectAccess is the support for null encryption for Windows 8.x DirectAccess clients using the IP-HTTPS IPv6 transition protocol. Using null encryption eliminates the overhead imposed by the needless encryption of DirectAccess IPsec communication, which itself is already encrypted. This double encryption significantly increases resource consumption on both the client and server, and can have a negative impact on scalability and performance. When a Windows 8.x client establishes an IP-HTTPS connection to a Windows Server 2012 or 2012 R2 DirectAccess server, it will negotiate only cipher suites that use null encryption. Windows 7 clients cannot take advantage of null encryption and continue to use encrypted cipher suites.

Note: It is possible to replicate some of the benefits of null encryption for Windows 7 clients using an Application Delivery Controller (ADC) such as the F5 Networks Local Traffic manager (LTM) to perform SSL offloading. See SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP for more information.

For both performance and scalability, the best deployment results are achieved when using a Windows Server 2012 or 2012 R2 DirectAccess server and Windows 8.x clients. However, null encryption for IP-HTTPS is no longer available in the scenario where client-based remote access VPN is configured on the same server as DirectAccess. As you can see below, when DirectAccess is deployed by itself, the server offers null encryption cipher suites which Windows 8.x clients can take advantage of.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

Figure 1 – Cipher Suites for DirectAccess Only

However, when the client-based remote access VPN role is enabled on the same DirectAccess server, null encryption cipher suites are no longer available for use by DirectAccess clients.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

Figure 2- Cipher Suites for DirectAccess and VPN

This occurs because the Secure Sockets Tunneling Protocol (SSTP) client-based remote access VPN protocol requires SSL/TLS encryption to provide confidentiality for tunneled network communication. Unfortunately, disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely. Of course none of this is readily apparent to the administrator, who may be completely unaware that they’ve sacrificed the efficiency of IP-HTTPS null encryption for Windows 8.x clients in order to support SSTP for client-based remote access VPN clients.

Note: There are additional scenarios in which null encryption for Windows 8.x DirectAccess clients is not supported. For example, if you enable the Web Application Proxy (WAP) role on the DirectAccess server, or if you configure DirectAccess to use one-time password (OTP) authentication, null encryption support is lost for Windows 8.x clients.

If you plan to support Windows 8.x clients using IP-HTTPS and want to take full advantage of the scalability and performance benefits associated with IP-HTTPS null encryption in Windows Server 2012/R2 DirectAccess, it is recommend that you deploy client-based remote access on a separate system.