[DirectAccess] Part 5: Troubleshooting guide for DirectAccess

In previous parts of this series, we configured DirectAccess on Windows Server 2012 (in core edition because that's fun and good for security !).

So now everything works ? Yes ? Perhaps, no ? ... That's right that DirectAccess is not always easy to troubleshoot.

In that article, I'll provide my feedbacks, my recommandations and my ideas to troubleshoot your environment.

• Part 1: Implementing a Basic DirectAccess configuration with IP-HTTPS on Windows Server 2012 Core
• Part 2: Reporting and Optimizing IP-HTTPS connections
• Part 3: Authenticating IP-HTTPS connections with a PKI certificate
• Part 4: Authenticating DirectAccess clients with certificates
• Part 5: Troubleshooting guide for DirectAccess
• Part 6: Configuring DirectAccess for Windows 7

PART 5: TROUBLESHOOTING GUIDE FOR DIRECTACCESS

1. IPv4 and IPv6

You now know that DirectAccess relies on IPv6. So what's different with IPv4 ?

Address are not 32 bits long, but 126 bits. That's all ? No IPv6 changes everything. Even ARP protocol is removed and replaced by ICMPv6.

I recommend you read some real good articles/white papers about IPv6 and IPv6/IPv4 transition technologies :

 - TCP IPv4 & IPv6 portal

 - How IPv6 Works

 - Introduction to IP Version 6

 - IPv6 Transition Technologies

 - IP on HTTPS

An IPv6 address is represented by a set of 8 groups of 4 hexadecimal digits. For example: 2001:0DB8:0000:2F3B:02AA:00FF:FE28:9C5A

Contrary to IPv4 where in general your interface use only one addresse, with IPv6, your interface use serveral address types for several purposes. Mainly you can see :

 - Global unicast addresses (equivalent to public IPv4 addresses): start with 2000::/3

 - Link local addresses (equivalent to 169.254.0.0/16): start with FE80::/64. Packages are never forwarded by routers

 - Site local addresses (equivalent to 10.0.0.0/8, 192.168.0.0/16...): start with FEC0::/10

 - Unique local addresses (improvement of site local addresses): start with FD00::/8

 - IPv4 compatible addresses: the 64 last bits look like 00:00:WX:YZ (where w.x.y.z is the dotted decimal representation of an IPv4 address).

Here is an example of network settings with DirectAccess enabled :

You certainly understand better now what you see !



2. IPHTTPS Connection Steps

The easiest tool to monitor connection is certainly netstat with the command line:

netstat -n -a

TcpView is also a great tools but for advanced troubleshooting.

So think KISS (Keep It Simple and Stupid) ;o)

  1. First of all, client try to reach the DirectAccess server with the HTTPS protocol (TCP/443)

  2. IPv6 arrives !! Client negotiates tunnel with HTTP protocol.

Question: What is fd5a:b763:7c6b:7777::c0a8:xxxx address ?

fd5a:b763:7c6b is the beginning of the addresses on the DirectAccess LAN

and C0A8:xxxx ? C0=192 A8=168... Obviously... that corresponds in hexa to the IPv4 address of my Domain Controller !!

DirectAccess Server translates in IPv6 format a IPv4 address. This is the mechanism used by directAccess to work with your IPv4 corporate network.

  3. Client contacts DNS server (UDP/53)

  4. You will certainly see other connections with other devices. You know now how to determine the IPv4 of the target device with the IPv6 address used.

Now that you know IPv6 and the connection process, Let's start troubleshooting !



3. Enable Windows Firewall

On my own experience, the most common issue concerns Windows Firewall:

DirectAccess connection is handled by the firewall Service. Windows Firewall must be enabled both on your DirectAccess Server and on your Clients.

On the clients, I recommend you enforce firewall both for Private and Guest networks.

On the DirectAccess server, network interface to check depends on your architecture. You must enable windows Firewall on the network interface where DirectAccess connections arrive.

So be careful: Often, windows firewall is disabled especially on domain networks.

If needed, you can create a GPO to enforce firewall for your server and/or your clients.
Here is my GPO to enable the firewall on my DirectAccess Server.

4.  Check DNS records

Setup Wizard automatically creates several DNS records. However, depending on you DNS scavenging settings (automatic DNS cleanup), records can be removed and It seems that directAccess never recreate them.

I recommend to disable the option "Delete this record when it becomes stale" for records concerning DirectAccess (you need to enabled the advanced mode in the view menu).

If some records have already been removed, you can easily recreate them:

Here is my own configuration. To simplify configuration, I used alias (CNAME) records.

To get the IPv6 address of the directaccess-corpConnectivityHost, you can search in the "DirectAccess Client Settings" GPO (Administrative Templates > Network/Network Connectivity Status Indicator).

5. Check Clients Settings

DirectAccess settings are provided by GPO on the clients and the servers. To check settings applied on your client, follow these steps:

  1. Connect your client on the internal network and force GPO update with the famous command line gpupdate /force

  2. Make sure that the DirectAccess GPO is correctly applied with the gpresult.exe tool.

You can use gpresult /r to get the list of GPO applied, but I recommend you create a full HTML report with the command line gpresult /h gpresult.html /f

Compare time and settings with your GPO to ensure you get all the latest settings from your DC.

If you have trouble to contact a DC see the chapter concerning NLS.

Now that you ensure DirectAccess GPO is correctly applied, you have 3 cmdlets to watch DirectAccess settings. Make sure that parameters are correct regarding your GPO and your infrastructure:

  3. Get-DnsClientNrptPolicy: that cmdlet is made to monitor NRPT Policy. NRPT policy manage DNS resolution that are made in and out DirectAccess Tunnel.

In the following screenshot, NRPT policy tells that name like *.SC.LAB (so my own internal domain) must be solved  and joined with the DirectAccess Server (DirectAccessDnsServer settings). However, the name DirectAccess-NLS.sc.lab must be solved normally.

Important point: If you try to contact a device directly with its IP address, that IP address will never be solved with DNS and NRPT policy. As a consequence your client will try to join that IP address directly on the Internet and not within DirectAccess on your corporate network unless you configure your client to send all connections (Internet and Corporate) in the DirectAccess Tunnel.

  4. Get-NCSIPolicyConfiguration: that cmdlet provide information about the Web Probe Host that is used by DirectAccess client computers to verify connectivity to the internal network.

  5. Get-NetIPHttpsConfiguration: that cmdlet provide information about the DirectAccess IPHTTPS connection.

6. Check HTTPS access and Certificate

Your Client is correctly configured !?! So let's check the IP-HTTPS connection.

  1. Connect now your client to a normal Internet connection, out of your internal network.

  2. In the previous chapter, we used cmdlet Get-NetIPHttpsConfiguration. Type the value of the ServerURL parameter (the public URL of your DirectAccess server) in your web brother BUT remove the last letter.

Normally, you get a HTTP 404 Error (that's normal, because we made intentionnaly a mistake on the URL) but your are now sure your DirectAccess is reachable.

If you get no response, that means certainly that your DNS is not properly configured or that HTTPS (443/TCP) port is not correctly configured.
Check prerequisites described in Part1 - chapter 3 Prepare your Network.


  3. Now, type the correct URL.

Nothing appears and your brother always wait for the page. That's normal !

If you get an error message concerning your certificat, this means that your certificat is not correctly trusted by your client.

Check the certificate and ensure your certificate is correctly trusted.

6. Network settings and DNS

For DirectAccess with  IP-HTTPS, you only have to open and forward the HTTPS (443/TCP) port (Part1 - chapter 3 Prepare your Network).

You must allow the DirectAccess server to reach at least the DNS server, the Domain Controller and the NLS server. By default, the NLS server is the DirectAccess server itself. If you move that role to an external HTTPS server, you must open the 443/TCP port from the DirectAccess server to that external NLS server.
For more information, see the NLS chapter.

Here are some cmdlet you can use to get status information on your client:

Get-DAConnectionStatus: To get the general status of your DirectAccess connection. That cmdlet is really useful to know if your client can reach your DirectAccess Server (proxy, bad network configuration...)

Get-NetIPHttpsStats: To get the status of the connection with IP-HTTPS protocol. That cmdlet is usefull if you suspect your client use other protocol than IP-HTTPS (See Part 2 - Chapter 2 Improve connection time)

Same command exists for other protocols:

7. Check Events

You can get logs from 2 components :

  1. CAPI2

The Capi2 service is in charge of certificates validation.

To get logs of that service, lauch the Event Viewer (Eventvwr.exe) and open Applications and Services logs > Microsoft > Windows > CAPI2 >Operational

By default, logs for that service are disabled. You need to enable them.

On your client, you will be able to ensure everything is ok with the certificates for computer, IPHTTPS connection, NLS...

Normally, you shoudn't see any error.

  2. Firewall logs

If you have trouble with the Windows Firewall, you can also check logs.
By default logs are disabled.

To enable logs :
 - type the command line : auditpol.exe /set /SubCategory:"MPSSVC rule-level Policy Change","Filtering Platform policy change","IPsec Main Mode","IPsec Quick Mode","IPsec Extended Mode","IPsec Driver","Other System Events","Filtering Platform Packet Drop","Filtering Platform Connection" /success:enable /failure:enable
- Restart the firewall service : net stop MPSSVC && net start MPSSVC

To read logs :
 - Lauch the Event Viewer (Eventvwr.exe) and open Windows Logs > Security

 - Click right and create a filter for the EnventIDs 4600-5500

The full process is described here.


8. NLS Server

Many issues also concern NLS Server.

NLS (for Network Location Server) helps the clients to know if they are on the internal network or out. Indeed, if client is able to contact and authenticate NLS, it considers that it is connected to the internal network.

NLS is either the DirectAccess server or an https server (called external server).

If you use the DirectAccess server as NLS server (default configuration) ensure your DirectAccess server can be joined on port 62000/TCP anywhere from your internal network. (for more information, see plan firewall requirement chapter on technet)

If you use an external server be sure:

- External server can be joined anywhere on your internal network (HTTPS port: 443/TCP)
- External server can be joined from the DirectAccess server (HTTPS port: 443/TCP)

- External server can't be joined from the Internet (don't use a public server like your OWA server)

Be careful is you apply changes on your NLS . Indeed, as long as your client is not able to contact the NLS, it considers that the resources on internal network are unavailable. As a consequence, you can't update GPO and DirectAccess configuration. If you completely lose your NLS, you may have to reinstall your clients...

I recommend to plan very carefully operations on NLS.

9. Monitor the configuration distribution status of the Remote Access server

You may experience issues when you udpdate configuration on your DirectAccess server.

I recommend you force GPO update with the command line gpupdate /force each time you apply changes. You will so ensure DirectAccess use right configuration.

To get more information about error messages, read Monitor the configuration distribution status of the Remote Access server on technet.


ADDENDUM 2013/07/24:
I forgot to show you how to generate logs in Windows 8.

 - Open your Network Connections and click-right on your DirectAccess Connection - Click on View connection properties

The  DirectAccess Properties panel opens
 - Click on the Collect Logs button

DirectAccess logs are generated...
 - Click on the View logs link

 - Open the HTML file...

The beginning is great...
Oops !! The following information is... not user friendly ;o)

... its better to open that file with Notepad.

On my mind, the reported information is not really usefull to troubleshoot your connection. The file is not as relevant as in Windows 7 (see next chapter).
However, if you have a remote user with troubles, it's easy to ask him to generate that file and to send it to you.

I hope that article helps you to troubleshoot your configuration and to understand how DirectAccess works.

In the next (bonus) article, I will provide you some feedback about how to configure DirectAccess for Windows 7.

See you soon
Julien