DirectAccess Connectivity Assistant – Reading the log file


Those DCA log files can be incredibly helpful in diagnosing a broken DirectAccess connection, and they can be very overwhelming at the same time. Here’s my take on a summary of each section, and some of the common statuses that could indicate trouble. I am basing this on the average, “normal” implementation so I won’t go into extended detail on a few of the results that are not used in the average installation:

Top of log file
At the very top you’ll see a quick summary of whether or not the DCA “thinks” it can see inside the corporate network successfully. It’s important to note that this overall status is not always accurate. For instance, if you have configured the DCA to probe more than one internal resource, it might be able to see one and not the other, and even though the DirectAccess tunnels are established correctly, it may still report “Corporate connectivity is not working correctly” – which is actually untrue.

Ipconfig /all
Pretty self-explanatory here. This shows all IP addresses on the client computer. You should have a local LAN IP address as well as at least one IPv6 address assigned from the Transition Technologies (6to4, Teredo or IP-HTTPS).

Netsh int teredo show state
This shows the particulars of Teredo. You want “Type” to be 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.

Netsh int httpstunnel show interfaces
This shows the details of the IP-HTTPS connection. If 6to4 or Teredo has made a successful connection, IP-HTTPS will show as “Disabled”. If you do not have 6to4 or Teredo connectivity, IP-HTTPS will show either “Active” or it will display an error code that will be useful for tracking down anything potentially wrong with the IP-HTTPS connection. Problems with IP-HTTPS are typically certificate related.

Netsh dns show state
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
Direct Access Settings : Configured and Enabled

Netsh name show policy
This should reflect the information you provided during the DirectAccess configuration wizards on the “DNS Suffixes” 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”.

Netsh name show effective
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).

Netsh adv mon show mmsa
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 (6to4, Teredo, IP-HTTPS), or you could have a problem with your computer certificate that is assigned to your computer not authenticating properly.

Netsh nap client show state
This lists information on the status of Network Access Protection on the client. If you are not using NAP certificates with your DA environment, this section can be ignored.

Wevtutil query –event Microsoft-Windows-NetworkAccessProtection…
Another section dedicated to NAP that can be ignored if NAP is not enforced.

Netsh int ipv6 show int level=verbose
Some statistics on your IPv6 interfaces, I have never found a case where the data here was necessary for any troubleshooting.

Netsh advf show currentprofile
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.

Netsh advfirewall monitor show consec
Some additional information about your firewall settings here, as well as another listing of the Security Associations (IPsec tunnels). The useful information here is really whether or not you can see your IPsec tunnels established, but that information is already available elsewhere in the logs.

Certutil –store my
This command lists the certificates that are installed on your client computer. For a successful DirectAccess connection, you must have a “Machine” certificate issued by your internal CA server that is valid.

Systeminfo
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, or Server 2008 R2, because those are the only Operating Systems that can be DirectAccess client computers.

Whoami /groups
Listing of the local computer groups that you are part of.

If there is anything you would like added to this list or detailed our further, please let me know and I will update accordingly. Thanks!

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com