DirectAccess Network Location Server Considerations
When deploying DirectAccess, acritical infrastructure component is the Network Location Server (NLS).The NLS is used by DirectAccess clients to determine if they are inside oroutside of the corporate network. Based on NLS reachability, theDirectAccess client will decide if it should attempt to establish DirectAccessconnectivity to the tunnel endpoints specified by the DirectAccessconfiguration. If the DirectAccess client can connect to the NLS, it assumes itis inside the corporate network anddoes 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 DirectAccessconnectivity. For this reason it is essential that the NLS be exempted from theName Resolution Policy Table (NRPT) and its hostname only be resolvable on theInternal network. The hostname of the NLS shouldnever be configured in public DNS. In addition, the NLS shouldnot be reachable via the public Internet.
Manyare confused about the NLS and what its specific configuration requirementsare. The NLS itself is nothing more than a web server with an SSL certificate installed. You canuse any web server youchoose, as long as it has a proper SSL certificate. The SSL certificate shouldbe valid and the subject name should match the name used in the DirectAccessconfiguration. The SSL certificate issued to the NLS should also be trusted bythe DirectAccess server and allclients. In addition, the NLS should be configured to allow inbound ICMP EchoRequests from the DirectAccess server.
Whenpreparing a NLS, virtual servers are typically deployed with minimal resources(CPU, memory, and disk), as the clients generate little traffic to thisservice. However, it is extremely important that the NLS be highly available.If the NLS is unavailable for any reason, clients on the Internalnetwork willnot be able to connect to it and will think they are outside of the corporate network. Whenthis happens they will load their NRPT and attempt to establish DirectAccessconnectivity. In this state, one of two scenarios plays out. First, and mostcommon, 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 willaccess all resources through the DirectAccess server. Although a more desirable situation thanthe first, it often results in degraded performance when compared to native,non-tunneled LAN connectivity.
Toeliminate the single point of failure for the NLS, it is advisable to configurea minimum of two NLS in a clustered, or load balanced array. If you are usingIIS on Windows Server, which is a common configuration, considerenabling Network LoadBalancing (NLB) and assigning a Virtual IP Address (VIP) to the cluster, withthe NLS hostname in DNS will resolving to the VIP. An external, third-partyload balancer (hardware or virtual) can also be leveraged to provide highavailability for the NLS. Third-party load balancers offer advanced featurescan capabilities when compared to NLB, but come with additional costs. Anotheralternative, although less desirable than load balancing, is to prepare anotherNLS toserver as a hot or cold standby. In thisconfiguration, 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 secondaryNLS. This solution involves manual intervention and is not generally recommended,as NLB is free and provides transparent redundancy.