Share via

Network Location Detection

  • Article

Updated: July 15, 2010

Applies To: Windows Server 2008 R2

Along with settings for Internet Protocol version 6 (IPv6) transition technologies, DirectAccess clients that are connected to the Internet rely on the following to perform transparent connectivity to intranet resources:

  • Name Resolution Policy Table (NRPT) rules for DirectAccess. These rules specify that the DirectAccess client forward Domain Name System (DNS) queries for fully qualified domain names (FQDNs) that match the intranet namespace to the IPv6 addresses of intranet DNS servers. This separates intranet traffic from Internet traffic.

  • Connection security rules for DirectAccess. These rules specify that the DirectAccess client create encrypted Internet Protocol security (IPsec) tunnels to access intranet resources. There is an infrastructure tunnel that allows the client to access intranet DNS servers and domain controllers and an intranet tunnel that allows access to the entire intranet. These tunnels require computer (infrastructure and intranet tunnels) and user (intranet tunnel) credentials. The connection security rules for DirectAccess tunnels are specified for the Private and Public firewall profiles.

When the DirectAccess client is connected to the intranet, the NRPT rules and connection security rules must be deactivated so that the DirectAccess client uses normal DNS name resolution methods and does not use IPsec tunnels to access intranet resources. Therefore, a DirectAccess client must be able to determine when it is connected to the intranet. This is known as network location detection.

Network location detection process

The Windows Network Location Awareness (NLA) service performs network location detection for every network state change, such as an Internet Protocol (IP) address change, and attempts to access a specific Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL). You configure the network location URL through the Location page of step 3 of the DirectAccess Setup Wizard:

  • If you select Network location server is run on a highly available server, the network location URL is the URL that you specify.

  • If you select Network location server is run on the DirectAccess server, the DirectAccess Setup Wizard determines the network location URL from the Subject field of the specified certificate.

DirectAccess clients receive the configuration of the network location URL from the DirectAccess client Group Policy object (Computer Configuration\Policies\Administrative Templates\Network\Network Connectivity Status Indicator\Domain Location Determination URL) and store it in the Windows Registry at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl.

When the network state changes, the NLA service adds the DirectAccess rules to the effective NRPT. If the client can access the network location URL successfully over SSL and receive a valid HTTP response indicating a successful connection, the NLA service removes the DirectAccess NRPT rules. Otherwise, the rules remain in the NRPT.

The detailed process is the following:

  1. Attempt to resolve the FQDN in the network location URL.

  2. The FQDN matches an exemption rule in the NRPT, which is configured by default by the DirectAccess Setup Wizard. Because the FQDN matches an exemption rule, perform a normal name resolution, which includes using interface-configured DNS servers.

  3. Using the IP address returned from name resolution, perform an HTTP GET of the network location URL (an HTTPS connection).

  4. Establish a Transmission Control Protocol (TCP) connection with port 443 at the resolved IP address.

  5. Perform Secure Sockets Layer (SSL) authentication for HTTPS and validate the SSL certificate from the network location server.

  6. Perform a certificate revocation check for the SSL certificate by checking the certificate revocation list (CRL) files in the CRL Distribution Point field.

If the DirectAccess client can also locate and authenticate with a domain controller, it switches the network to the Domain profile. Because the DirectAccess connection security rules are specified only for the Private and Public profiles, they are deactivated.

With the combination of network location detection and computer domain logon, the DirectAccess client configures itself for normal intranet access.

Note

To demonstrate network location detection and its impact on the NRPT and connection security rules in the DirectAccess test lab (https://go.microsoft.com/fwlink/?Linkid=150613), do the following:

  1. Connect CLIENT1 to the Internet subnet.

  2. Open a Command Prompt.

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

    Notice that the Machine Location field states Outside corporate network.

  4. Run the netsh namespace show effectivepolicy command.

    Notice that there are two active NRPT rules: A namespace rule for corp.contoso.com and an exemption rule for nls.corp.contoso.com.

  5. Open the Windows Firewall with Advanced Security snap-in (wf.msc).

  6. From the console tree of the Windows Firewall with Advanced Security snap-in, open Monitoring\Connection Security Rules.

    In the details pane, notice that there are three connection security rules: DirectAccess Policy-ClientToCorp, DirectAccess Policy-ClientToDnsDc, and DirectAccess Policy-clientToNlaExempt.

  7. Disconnect CLIENT1 from the Internet subnet and connect it to the Corpnet subnet.

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

    Notice that the Machine Location field states Inside corporate network.

  9. Run the netsh namespace show effectivepolicy command.

    Notice that there are now no active NRPT rules.

  10. Refresh the details pane of the Windows Firewall with Advanced Security snap-in (Monitoring\Connection Security Rules).

    Notice that there are now no connection security rules.

Network location detection failures and their consequences

There are many reasons why the HTTP GET of the network location URL could fail, including the following:

  • Network location server is offline

  • A link failure makes the network location server unreachable

  • Cannot resolve FQDN of the network location URL

  • Incorrect address for the FQDN of the network location URL

  • Cannot establish the SSL session (TCP)

  • Cannot validate the SSL certificate due to certificate expiration, incorrect object identifier (OID), incorrect Subject field

  • Cannot resolve the FQDN of the CRL distribution point

  • Cannot reach the CRL distribution point

  • Cannot read the CRL files

The behavior of a DirectAccess client on the intranet when it cannot perform a successful network location detection depends on the name used by applications to access intranet resources, either FQDN or single-label, and whether the DirectAccess client can reach the Internet interface of the DirectAccess server.

If the DirectAccess client cannot reach the Internet interface of the DirectAccess server and tries to resolve an intranet FQDN, name resolution fails because there is no fall back behavior for FQDNs. Therefore, the DirectAccess client cannot reach the intranet resource.

If the DirectAccess client cannot reach the Internet interface of the DirectAccess server and tries to resolve a single-label name, fall back behavior can use LLMNR or NetBIOS methods, including WINS. Therefore, connectivity to the intranet resource can use IPv4, rather than IPv6.

A DirectAccess client on the intranet can use Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) and an intranet proxy server to reach the Internet interface of the DirectAccess server. In this case, all DirectAccess tunneled traffic is exchanged with the DirectAccess server over the IP-HTTPS session out to the Internet and back to the intranet via the DirectAccess server.

In this configuration, the DirectAccess client behaves in much the same way as if it were located on the Internet. However, intranet resources that are not available over DirectAccess are still unavailable, even though the DirectAccess client is connected to the intranet. Additionally, intranet access can have decreased performance because the traffic is routed through the IP-HTTPS session, out to the Internet, and back through the DirectAccess server.

Troubleshooting network location detection

To troubleshoot problems with network location detection, see the following: