[Note: this article was originally published on the Edge Man blog over at http://blogs.technet.com/b/tomshinder/archive/2010/07/19/what-defines-a-functional-connection-to-a-network-location-server.aspx. Please feel free to enhance and improve this article!]

===============================================================

One of the key pieces of a working DirectAccess solution is the Network Location Server or NLS. The purpose of the Network Location Server is to help the computer configured as a DirectAccess client to know that it’s inside the corporate network. When the DirectAccess client is inside the corporate network, you don’t want it to use the DirectAccess tunnels to reach internal resources. Instead you want the DirectAccess client to connect directly to the resources when they’re on the corporate network.

There are actually two primary things that happen when the computer configured as a DirectAccess client enters the internal network:

• The DirectAccess client connects to the Network Location Server (NLS) using an HTTPS connection. If the connection is successful, then the Name Resolution Policy Table (NRPT) is disabled and the DirectAccess client resolves names using the DNS server addresses defined on its network interface(s)
• The DirectAccess client is able to connect to a domain controller on the corporate network, which causes the Windows Firewall with Advanced Security to apply the Domain Profile, as you can see in the figure below. The domain Profile does not include the Connection Security Rules that are required to establish the DirectAccess IPsec tunnels

 
Figure 1

You can tell that the NRPT has disabled itself by running the netsh namespace show effectivepolicy command. You’ll see the Note: DirectAccess settings would be turned off when computer is inside corporate network, as seen in the figure below.

Figure 2

Conversely, if the DirectAccess client can’t find a domain controller and it can’t connect to the Network Location Server, then it will try to enable the DirectAccess IPsec tunnels and it will enable the Name Resolution Policy Table (NRPT). When the NRPT is enabled, name resolution for requests for intranet resources will be sent over the DirectAccess tunnels (if they can be established) and resolved by the UAG DNS64 DNS proxy.

If the DirectAccess client can’t establish the DirectAccess tunnels to connect to the DNS64 component, then name resolution requests for intranet resources will fail. As you can imagine, not being able to resolve names on the intranet can have some pretty negative consequences, some of which I describe at http://blogs.technet.com/b/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx and http://blogs.technet.com/b/tomshinder/archive/2010/04/06/when-good-network-location-servers-go-bad-preparing-against-nls-failure.aspx

The Mystery of the Working Network Location Server that Did Not Work

Which brings us to a case we encountered a couple of weeks ago. Everything was set up right:

• Certificates – check
• Network Location Server – check
• DA client and server GPOs deployed – check
• Infrastructure and intranet tunnels established when DA client outside the name – check
• Security Groups for DA clients – check

Things looked perfect. However, when the DA clients were returned to the intranet, the NRPT would not turn itself off. This would be consistent with a problem connecting to the NLS, but when we pointed the browser to the NLS, the default web page came up fine.

We did a network trace using NetMon 3.4 (click to download) and found that the DA client was making repeated connection attempts to the NLS. This was a bit strange, so we dug deeper.

We found out that the web server (a non-IIS server, but that’s no problem, we support any web server for the NLS server) was returning a bad header. This lead WinHTTP to not be able to parse the web page response and conclude that there was a server failure. In contrast, when we connected to the site using the web browser (IE), the bad header was ignored by WinInet (used by IE) and the page was successfully rendered in the browser.

What surprised me about this was that I had the impression that all we needed to do for a successful NLS connection was to successfully establish an SSL connection to the NLS and receive a 200 OK response from the web server. In fact, we need a little more than that – WinHTTP needs to be able to successfully parse the web page response in order to create a successful NLS connection.

I don’t expect this to be an issue for the vast majority of DirectAccess admins, but it might be something to keep in your back pocket if you’re having problems with the NRPT not being disabled when the DirectAccess clients are on the intranet and when you are using non-IIS servers for your NLS server, where you’re more likely going to customize the headers and thus might experience a typo in the process.

This article was originally written by:

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder