Troubleshooting commands for DirectAccess client connections

Many years ago I wrote a blog post regarding the (then current) Windows 7 DirectAccess Connectivity Assistant (DCA) log file and how to make sense of the contents when troubleshooting a Microsoft DirectAccess connection from the client’s perspective. While Windows 8 and 10 now have an updated Network Connectivity Assistant (NCA) with an updated logging mechanism, I find that the newer log files are less helpful for diagnosing a broken connection, and still find myself preferring to run many of the commands from the DCA days. Today I wanted to list the most common DirectAccess troubleshooting commands that I employ regularly, and explanations of those commands. Remember, these are all commands that you would run on a DirectAccess client machine (Windows 7, 8, or 10), and won’t necessarily give you any helpful information if run on the DA server side.

This is a great first step to figuring out whether a DA connection is working or not. What you should see is a valid IP address on your NIC, of course, and in addition to that you should see at least one IPv6 address listed for one of the DirectAccess transition technologies. Most commonly you will see an IP-HTTPS adapter listed, and it should have an IPv6 address associated with it (on a working DA connection). In many installs we still also utilize the Teredo protocol, so you may find an IPv6 address assigned to the Teredo adapter. You could even see two IPv6 addresses listed, one for Teredo and one for IP-HTTPS, and this is also pretty normal behavior.
What to watch for: Near the top of the ipconfig, where you see the IP addresses listed for your local NICs – the first red flag that I always look for is the existence of a native IPv6 address assigned to your NIC. This is different from the IPv6 addresses assigned to your transition adapters mentioned above (those are good) – if your home router, coffee shop router, or wherever you happen to be sitting has assigned you a native IPv6 address on the internet, you will see it right in your NIC properties and usually these addresses start with 2600:, 2602:, or something similar. If you find a native IPv6 address, this could interfere with your DirectAccess connection. For more detail on this situation, please see the following posts:
Native IPv6 addresses can break DirectAccess
DirectAccess – Using the DisabledComponents regkey to your advantage

This shows the details of your Teredo adapter. Not all DirectAccess implementations make use of Teredo, so you might see a “disabled” status, or even some information about a generic Microsoft Teredo relay listed here. If your DA deployment does use Teredo, then you want to look for the “Type” to be set to either “client” or “enterpriseclient” and when Teredo is successfully connected, it will show a “State” of “qualified”. If Teredo cannot connect, it is likely because of a port restricted firewall blocking UDP on the user’s internet connection, and Teredo will report “Primary server unreachable over UDP”. However, this should not cause too much concern, because if Teredo is unable to connect, IP-HTTPS should automatically connect and establish the DA tunnels that way.

This shows the details of the IP-HTTPS connection. If Teredo has made a successful connection, then typically IP-HTTPS will show as “Disabled”. If you do not have Teredo connectivity, then IP-HTTPS should be handling the connection and show “Active”. If unable to connect for some reason, there will be an error code listed that is useful for tracking down the issue with IP-HTTPS. Many times problems with IP-HTTPS connecting are related to the SSL certificate that is installed on the DA server.

These are the 3 important pieces here that you want to ensure are set correctly:
Network Location Behavior : Let Network ID determine when Direct Access settings are to be used
Machine Location : Outside corporate network (this will say Inside corporate network when you are plugged into the company LAN)
Direct Access Settings : Configured and Enabled
Note: If “Network Location Behavior” shows “Never use Direct Access settings” then take a look at the following post for detail on fixing that behavior: Network Location Behavior: Never use Direct Access settings

This should reflect the information you provided during the DirectAccess configuration wizards inside Step 3, on the “DNS” screen. This lists the NRPT (Name Resolution Policy Table) which determines what names go through the DA tunnels, and what names do not. If you do not have any information listed here, your machine has probably not received the settings from the DA Client GPO yet, and you should bring the laptop back into the corporate network for a “gpupdate /force”.

When outside the corporate network, this should show the same information as “netsh name show policy” above. If it does not, then you likely have a problem of the client machine not correctly realizing that it is outside of the corporate network, or the NRPT being forced to turn off for some reason (double check the settings in “netsh dns show state” to ensure they are set correctly as indicated above). When you are inside the corporate network, running “netsh name show effective” will display a simple message about DirectAccess settings being turned off when inside the corporate network.

This is a listing of your Security Associations, which are basically your IPsec tunnels. You should have tunnels here that have a second authentication of “UserNTLM” which indicates the “Infrastructure Tunnel”, as well as tunnels with a second authentication of “UserKerb” indicating the “Intranet Tunnel”. If you do not have any tunnels listed here, DA is not working. You could have a problem with the Transition Technologies not establishing (Teredo or IP-HTTPS), or you could have a problem with your computer certificate that is assigned to your computer not authenticating properly.

This command lists the certificates that are installed on your client computer. In a basic DirectAccess implementation, you may not utilize certificates for authentication and so won’t see any here. But for any IVO Networks customers, or anyone running a best practices DirectAccess implementation, we always utilize machine certificates for tunnel authentication, and so in this case you need to check this list for the existence of that valid machine certificate from your internal CA server. If you are missing your machine certificate, or if it has expired, this will cause your DirectAccess IPsec tunnel creations to fail.

This shows which Windows Firewall profile your current internet connection has been assigned. You want to ensure that you have either “Public” or “Private” Profile Settings because the DirectAccess Connection Security Rules are only activated while connected to network in which Windows Firewall has been set to use the Public or Private profile settings. You also want to ensure that the Firewall “State” is ON. If set to OFF, you need to figure out what is disabling your Windows Firewall and change it, because WFAS is necessary for a successful DirectAccess connection.

Some general information about the client computer where you are running DirectAccess. Typically I only check the “OS Name” – you want to make sure the client is running either Windows 7 Enterprise, Windows 7 Ultimate, Windows 8 Enterprise, Windows 10 Enterprise or Education. These are the only client Operating Systems that can be DirectAccess client computers.

The updated information provided here should assist with troubleshooting DirectAccess connections from a client laptop. If there are any additional commands you find particularly useful, please let me know and I will update the list!

Jordan Krause
IVO Networks