DirectAccess Network Location Server Considerations

When deploying DirectAccess, a critical infrastructure component is the Network Location Server (NLS). The NLS is used by DirectAccess clients to determine if they are inside or outside of the corporate network. Based on NLS reachability, the DirectAccess client will decide if it should attempt to establish DirectAccess connectivity to the tunnel endpoints specified by the DirectAccess configuration. If the DirectAccess client can connect to the NLS, it assumes it is inside the corporate network and does not establish DirectAccess connectivity. If it cannot connect to the NLS, the DirectAccess client assumes it is outside of the corporate network and attempts to establish DirectAccess connectivity. For this reason it is essential that the NLS be exempted from the Name Resolution Policy Table (NRPT) and its hostname only be resolvable on the Internal network. The hostname of the NLS should never be configured in public DNS. In addition, the NLS should not be reachable via the public Internet.

Many are confused about the NLS and what its specific configuration requirements are. The NLS itself is nothing more than a web server with an SSL certificate installed. You can use any web server you choose, as long as it has a proper SSL certificate. The SSL certificate should be valid and the subject name should match the name used in the DirectAccess configuration. The SSL certificate issued to the NLS should also be trusted by the DirectAccess server and all clients. In addition, the NLS should be configured to allow inbound ICMP Echo Requests from the DirectAccess server. 

When preparing a NLS, virtual servers are typically deployed with minimal resources (CPU, memory, and disk), as the clients generate little traffic to this service. However, it is extremely important that the NLS be highly available. If the NLS is unavailable for any reason, clients on the Internal network will not be able to connect to it and will think they are outside of the corporate network. When this happens they will load their NRPT and attempt to establish DirectAccess connectivity. In this state, one of two scenarios plays out. First, and most common, the DirectAccess connection will fail, leaving clients on the Internal network unable to reach internal corporate network resources until the NLS is back online. Second, if the DirectAccess server’s external network interface is reachable from the corporate network, DirectAccess communication will be established and DirectAccess clients will access all resources through the DirectAccess server. Although a more desirable situation than the first, it often results in degraded performance when compared to native, non-tunneled LAN connectivity.

To eliminate the single point of failure for the NLS, it is advisable to configure a minimum of two NLS in a clustered, or load balanced array. If you are using IIS on Windows Server, which is a common configuration, consider enabling Network Load Balancing (NLB) and assigning a Virtual IP Address (VIP) to the cluster, with the NLS hostname in DNS will resolving to the VIP. An external, third-party load balancer (hardware or virtual) can also be leveraged to provide high availability for the NLS. Third-party load balancers offer advanced features can capabilities when compared to NLB, but come with additional costs. Another alternative, although less desirable than load balancing, is to prepare another NLS to server as a hot or cold standby. In this configuration, a DNS CNAME record for NLS is used to point to the primary NLS. In the event of a failure, the DNS record is updated to point to the secondary NLS. This solution involves manual intervention and is not generally recommended, as NLB is free and provides transparent redundancy.