DirectAccess DNS Records Explained

After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.

DirectAccess DNS Records Explained

Figure 1 – DirectAccess DNS records for IPv4-only network.

DirectAccess DNS Records Explained

Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.

Here is a detailed description for each of these DirectAccess DNS entries.

directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to 127.0.0.1, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of 127.0.0.1). When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.

This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. directaccess-corpConnectivityHost.corp.example.net) to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.

Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).

directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.

This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.

If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.

DirectAccess Load Balancing and Multisite Configuration Options Unavailable

Looking for more information about DirectAccess load balancing? See my post entitled DirectAccess Deployment Guide for Kemp LoadMaster Load Balancers.

DirectAccess in Windows Server 2012 R2 supports load balancing and multisite configuration options to provide both local and geographic redundancy, respectively. To configure either of these options, open the Remote Access Management console, expand Configuration in the navigation tree, highlight DirectAccess and VPN, and then select either Enable Multisite or Enable Load Balancing in the Tasks pane.

DirectAccess Load Balancing and Multisite Configuration Options Unavailable

Depending on your configuration you may encounter a scenario in which these features do not appear in the Remote Access Management console.

DirectAccess Load Balancing and Multisite Configuration Options Unavailable

This occurs when the Web Application Proxy (WAP) role is installed on the DirectAccess server. Although this is a supported configuration, enabling load balancing or multisite on a DirectAccess server with WAP installed requires additional configuration. Specifically, load balancing and/or multisite must be configured before installing the WAP role.

To restore support for load balancing and multisite configuration options, remove the WAP role using the GUI or with the Uninstall-WindowsFeature Web-Application-Proxy PowerShell command.

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)