Network Location Detection

Published: April 29, 2010

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\NetworkConnectivityStatus
Indicator\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 (http://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.