DirectAccess Client Determines that it is on the Internet When on the Intranet

  • Article

Updated: November 18, 2009

Applies To: Windows Server 2008 R2

If the DirectAccess client cannot access the Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL) hosted by the network location server when directly attached to the intranet, network location detection determines that a DirectAccess client is on the Internet and keeps the DirectAccess-based rules in the effective Name Resolution Policy Table (NRPT). With the DirectAccess-based rules in the effective NRPT, the DirectAccess client sends Domain Name System (DNS) queries for names that match the intranet namespace to the Internet Protocol version 6 (IPv6) addresses of intranet DNS servers.

If you have native IPv6 connectivity and the IPv6 addresses of the DNS servers configured in the namespace rules are reachable, the DirectAccess client will be able to successfully resolve and connect to intranet DNS servers. However, if the NRPT rules use a different set of DNS servers than intranet computers through interface-configured DNS servers (for example, to place the load of DirectAccess and intranet clients on different sets of DNS servers), DirectAccess clients on the intranet will continue to use the DNS servers that are intended for use by DirectAccess clients on the Internet.

To determine the results of network location detection on a DirectAccess client

  1. On the DirectAccess client, start a command prompt as an administrator.

  2. From the Command Prompt window, run the netsh namespace show policy command.

    There should be set of NRPT rules. If not, this DirectAccess client has not received its NRPT rules from computer configuration Group Policy. Verify that this computer is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2 and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard.

  3. From the Command Prompt window, run the netsh dnsclient show state command.

    The determined network location is displayed in the Machine Location field (Outside corporate network or Inside corporate network).

  4. To investigate the details of network location detection, click Start, type eventvwr.msc, and then press ENTER.

  5. In the console tree, open Application and Services Logs\Microsoft\Windows\NCSI\Operational.

  6. Double-click the most recent Information events with the event ID 4010.

    The text on the General tab displays the result of the latest detections (also known as Inside/Outside detections) as either INSIDE or OUTSIDE. INSIDE means the intranet has been detected. OUTSIDE means that the intranet has not been detected. Look at the events for the interfaces with interface numbers that begin with 0x47 (WLAN) and 0x60 (LAN). If any of the LAN or WLAN interfaces are INSIDE, the DirectAccess client is on the intranet. If all of the LAN and WLAN interfaces are OUTSIDE, the DirectAccess client is not on the intranet.

Note

You can also use the wevtutil qe Microsoft-Windows-NCSI/Operational /rd:true /f:text >> filename.log command to export the events to a text file.

To troubleshoot why a DirectAccess client on the intranet cannot successfully access the network location URL

  1. On the DirectAccess client, start a command prompt as an administrator.

  2. From the Command Prompt window, run the reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v DomainLocationDeterminationUrl command.

    This displays the network location URL. If there is no value, the DirectAccess client has not been properly configured with computer configuration Group Policy. Verify that this computer is running Windows 7 Ultimate Edition or Windows 7 Enterprise Edition and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard.

  3. From the Command Prompt window, run the netsh namespace show policy command.

  4. Compare the FQDN in the network location URL to the NRPT rules from step 3.

    Either the FQDN should not match the DirectAccess-based intranet namespace rules or it should match an exemption rule for the FQDN. In either case, the DirectAccess client will use interface-configured DNS server to resolve the FQDN in the network location URL.

  5. From the Command Prompt window, ping the FQDN in the network location URL.

    This step ensures that the DirectAccess client can resolve the name and reach the network location server.

  6. Attempt to access the network location URL with your Internet browser.

    You should see the Web page without any certificate errors. Note that the contents of the Web page do not matter, only the ability to successfully access it.

If you see a certificate error, verify the following for the certificate on the network location server that is being used for HTTPS (SSL)-based connections:

  • The DirectAccess client can validate and trust the network location certificate.

  • The Subject field is the FQDN from the network location URL.

  • The Enhanced Key Usage field contains the Server Authentication object identifier (OID).

  • The certificate revocation list (CRL) Distribution Points field contains at least one CRL distribution point that the DirectAccess client can successfully access.

To test access to the CRL distribution points of the network location certificate from a DirectAccess client on the intranet

  1. On the network location server, obtain the CRL distribution points—the Hypertext Transfer Protocol (HTTP) URL without the file name or the universal naming convention (UNC) path without the file name—from the CRL Distribution Points field of the certificate being used for HTTPS-based connections. If the network location server is running Windows, use the Certificates snap-in for the local computer store and view the Details tab for the properties of the HTTPS (Secure Sockets Layer [SSL]) certificate.

  2. On the DirectAccess client, start a command prompt as an administrator.

  3. From the Command Prompt window, ping the FQDNs from the URLs or UNC paths for the CRL distribution points obtained in step 1.

    This step ensures that the DirectAccess client can resolve the names of the CRL distribution point locations and reach the resolved addresses.

  4. For a URL-based CRL distribution point, paste it into your Internet browser. You should see a series of files with the .crl extension. Ensure that you can open all of the .crl files.

  5. For a UNC path-based CRL distribution point, click Start, type the path, and then press ENTER. You should see folder with a series of files with the .crl extension. Ensure that you can open all of the .crl files.

The DirectAccess client must be able to access at least one of the CRL distribution points and open the CRL files. Otherwise, certificate revocation fails and the DirectAccess determines that it is on the Internet.

For more information about the technical details of the network location detection process, see Network Location Detection.