This troubleshooting scenario is for the DirectAccess test lab for Windows Server 2008 R2. For information about test lab troubleshooting scenarios, click here.
When connecting to any network, a DirectAccess client attempts to access its network location server, a Web server that is only available on the intranet. If a DirectAccess client cannot successfully access the network location server when connected to its intranet, depending on its configuration, it cannot resolve intranet DNS names.
In this troubleshooting scenario, you configure the DNS Host (A) record for the network location server name (nls.corp.contoso.com) to use the wrong IP address, and then troubleshoot the results.
Follow these steps to configure the DirectAccess test lab for this troubleshooting scenario.
From the previous procedure, it appears that DC1, the intranet DNS server, is not resolving intranet names for CLIENT1 even when it is directly attached to the intranet. The following procedure uses the appropriate steps in DirectAccess Client Determines that it is on the Internet When on the Intranet to determine the root cause of the problem.
This is the root cause of the problem. Because nls.corp.contoso.com is resolving to the IP address of EDGE1 (rather than APP1), CLIENT1 is attempting to access the default web page of EDGE1 for network location detection. For SSL-based Web connections, the FQDN in the Subject field of the certificate offered by the web server must match the FQDN of the URL that is being used to access the Web site. Because IIS on EDGE1 is configured to offer the IP-HTTPS certificate with the Subject name of edge1.contoso.com, network location detection fails and CLIENT1 determines that it is connected to the Internet, rather than the intranet.
Follow these steps to correct the configuration of the DirectAccess test lab for this troubleshooting scenario.