7 Steps for Troubleshooting DirectAccess Clients

by [Published on 19 Aug. 2010 / Last Updated on 19 Aug. 2010]

7 easy steps to help troubleshoot DirectAccess clients.

Introduction

DirectAccess is the new Microsoft remote access technology that allows you to always be connected to your company network no matter where you are. In addition, DirectAccess allows corporate IT to always be connected to their managed assets, so that those systems are always managed, always up to date, always compliant and always under the control of corporate IT. DirectAccess is enabled by the combination of Windows 7 and Windows Server 2008 R2, and it’s perfected when you add the Unified Access Gateway (UAG) 2010 to the mix. While DirectAccess is possible without UAG, it really isn’t a viable enterprise-ready solution without it.

I’ve been using DirectAccess for quite a while now and I don’t know what I would do without it. It’s an amazing thing to always be connected. I don’t have to think about starting a VPN connection, don’t have to worry about whether the VPN connection will work, and I don’t have to deal with crummy web-based applications that are reachable through an SSL VPN gateway. With DirectAccess, I get to use my rich desktop applications on my rich client platform to put out quality work without ever thinking about connectivity. I’m just connected. From the user point of view, it’s a dream come true.

However, as an admin, you might have to troubleshoot DirectAccess connections from time to time. While DirectAccess connections are pretty reliable, nothing is perfect and there are going to be the occasional times when clients can’t connect and you have to figure out what the problem is. That’s what we’re going to discuss in this article today:  some basic steps you can take to troubleshoot DirectAccess client connections.

Based on both Microsoft’s documentation and my own trial and error, here is my seven step plan to troubleshooting DirectAccess client connectivity:

  • Confirm that the DirectAccess clients have received their Group Policy Settings
  • Confirm that the client knows that it’s not on the intranet
  • Confirm the NRPT settings on the DirectAccess client
  • Confirm the IPv6 address on the DirectAccess client
  • Confirm authentication for the DirectAccess tunnels
  • Confirm that connectivity to DNS and domain controllers is working

Now let’s look at each of these steps in more detail.

Confirm Group Policy Settings

DirectAccess clients get their DirectAccess client settings via Group Policy. So if Group Policy isn’t applied to the DirectAccess client, then the DirectAccess client isn’t going to be able to act like a DirectAccess client. There are many ways you can confirm the Group Policy settings on the DirectAccess client, but my favorite way is to just check the Windows Firewall for the Connection Security Rules that DirectAccess clients use to connect to the UAG DirectAccess server. These rules are assigned by Group Policy, so if they’re there, then Group Policy has been assigned.

You can type wf.msc in the Search box on the Windows 7 computer to open the Windows Firewall with Advanced Security console. In the left pane of the console, click on the Connection Security Rules node.


Figure 1

If you see the three rules shown in Figure 1: UAG DirectAccess Client – Clients Access Enabling Tunnel – All, UAG DirectAccess Clients – Clients Corp Tunnel and UAG DirectAccess Clients – Example NLA, then you know that Group Policy has been applied.

Confirm that the Client Knows that it’s not on the Intranet

The DirectAccess client needs to know whether it’s on or off the corporate network. If it’s on the corporate network, then it will turn off the DirectAccess tunnels and use local name resolution based on the DNS server that’s configured on its NIC. If the DirectAccess client is off the corporate network, then it will establish the DirectAccess tunnels to connect to the UAG DirectAccess server, and let the UAG DirectAccess server resolve names for the DirectAccess client.

You can quickly determine if the DirectAccess client knows whether it’s on or off the network by using the following command:

netshdns show state

This command should return a result something likeFigure 2 below.


Figure 2

As you can see in the figure, the machine location is reported as Outside corporate network. If the machine had reported that it was in the corporate network when it was not, then you would have to figure out why it’s reporting that. If the machine is reporting that its outside the corporate network when it is on the network, then you’ll have to figure out why it thinks it’s off the network. In the latter case, it’s most likely that there is a problem connecting to the Network Location Server (NLS).

Confirm the Name Resolution Policy Table Settings on the DirectAccess Client

The Name Resolution Policy Table (NRPT) is used by the DirectAccess client to determine which DNS server it should use to resolve a name. When the DirectAccess client is on the intranet, the NRPT is turned off and the only DNS server the client uses is the DNS server that’s configured on its NIC. However, when the DirectAccess client is off the corporate network, the NRPT turns itself on and is used to determine which DNS server it will use to resolve names based on the name that needs to be resolved.

You can view the NRPT settings by using the command:

netsh namespace show effectivepolicy


Figure 3

Here you can see, in Figure 3, that any name in the corp.contoso.com domain will be sent to the DNS server at 2002:836b:3::836b:3, which is the 6to4 address on the UAG DirectAccess server. The UAG DirectAccess server is used as the DNS server because the UAG DirectAccess uses DNS64 as a DNS proxy for the DirectAccess clients. Notice the name nls.corp.contoso.com has no DNS server address listed for it, as it represents an exception from the servers in the corp.contoso.comcollection. The reason for this is that you don’t want the DirectAccess client to connect to the NLS when it’s not on the corpnet, since the DirectAccess client uses connectivity to the NLS to define when it is on the corpnet!

Confirm the IPv6 Addresses on the DirectAccess Client

DirectAccess clients use IPv6 to communicate with the DirectAccess server. That is always true. The DirectAccess client might also use IPv6 to communicate with resources on the intranet. This will be true if the intranet resource is IPv6 capable. However, if the intranet resource is not IPv6 capable, then the UAG DirectAccess server will use NAT64/DNS64 to translate the IPv6 messages from the DirectAccess client to the IPv4 resource on the intranet. It’s important to understand that the DirectAccess client is always using IPv6 when connecting to the UAG DirectAccess server.

However, since the IPv6 Internet doesn’t really exist yet for most of us, we need to move the IPv6 messages over an IPv4 Internet, and we do that by using IPv6 transition technologies. The DirectAccess client can use one of three IPv6 transition technologies to connect to the UAG DirectAccess server over the IPv4 Internet:

  • 6to4
  • Teredo
  • IP-HTTPS

You can determine which IPv6 transition technology is being used by issuing an ipconfig /all command.


Figure 4

In Figure 4 above, you can see that the Tunnel adapter 6TO4 Adapter is being used to connect to the UAG DirectAccess server and that it has an IP address and default gateway assigned to it. The default gateway you see here is the 6to4 address of the UAG DirectAccess server.

When troubleshooting the DirectAccess client, make sure it has an IPv6 address. If there is no IPv6 address, that indicates that there is a problem with the IPv6 configuration of the client and you should focus your efforts there. There may also be connectivity issues to the UAG DirectAccess server, so make sure you can ping the IPv6 address of the UAG server, such as the IPv6 you see as the default gateway for the 6to4 adapter.

Confirm DirectAccess Client Authentication

When the DirectAccess client connects to the UAG DirectAccess server, it uses IPsec tunnels to allow connectivity to the corpnet. There are two tunnels that are used:

  • The Infrastructure Tunnel – this tunnel is established before the user logs on, using a computer certificate and the computer’s user account in Active Directory and NTLMv2 authentication. So two authentication methods are used to establish the first tunnel and the DirectAccess client can only access a subset of computers over the infrastructure tunnel.

  • The Intranet Tunnel – this tunnel is established after the infrastructure tunnel is established, as the infrastructure tunnel is required to enable access to the domain controllers for Kerberos authentication. The intranet tunnel uses computer certificate authentication and logged on user account (Kerberos) authentication to create the second tunnel. The intranet tunnel allows the user to connect to the rest of the network.

The question is: how do you see which authentication mechanism is being used and what is and isn’t working? One way you can find out is by once again using the Windows Firewall with Advanced Security console. Expand the Monitoring node and then expand the Security Associations node and then click on the Main Mode node. Here you can see the Main Mode security associations for the infrastructure and intranet tunnels, as shown in Figure 5. Notice that in the 2nd Authentication Method section, there are connections using NLTMv2 and Kerberos V5. NTLM is used to authenticate the infrastructure tunnel, and Kerberos is used for the intranet tunnel.


Figure 5

You typically won’t have problems with NTLM authentication. More often, you’ll see problems with Kerberos authentication. Make sure the user account isn’t disabled and ensure that the user account is using the current password and not a cached password. Note that you won’t see any Kerberos intranet tunnel connections until you try to connect to a resource that isn’t part of the collection of servers that you denoted as infrastructure servers. Those connections go through the NTLM authenticated infrastructure tunnel.

Confirm Connectivity to DNS Servers and Domain Controllers

Just as in non-DirectAccess troubleshooting scenarios, you need to make sure that the DirectAccess client can contact domain controllers and DNS servers.

For example, you can run the command:

nltest /dsgetdc:

and you should get a result that’s something like what appears in Figure 6 below. This shows that the DirectAccess client was able to connect to a domain controller and it also provides information about the IPv6 address of the domain controller. Note that if the domain controller didn’t have an IPv6 address, you would still see an IPv6 address here, but it would be a NAT64 address.


Figure 6

You can easily test name resolution with ping, as you see in Figure 7 below.


Figure 7

If you can’t ping a resource by name, check to determine whether you can ping the resource using its IPv6 address. If the resource isn’t IPv6 capable, you can ping it using its NAT64 address. For instructions on how to calculate the NAT64 address for the IPv4 only host, you can use the information in Tom’s blog post here.

Summary

In this article, we went through a short introduction on how to troubleshoot the DirectAccess client. By checking out these seven issues, you should be able to get the information you need to move your troubleshooting efforts in the right direction. If you want to learn more about UAG DirectAccess, a great place to start is with the UAG DirectAccess troubleshooting Test Lab Guide, which you can find over here. Let me know if you have any questions about troubleshooting UAG DirectAccess and I’ll do what I can to point you in the right direction. Thanks! –Deb.

Advertisement

Featured Links