Top 5 DirectAccess Troubleshooting Tips

Top 5 DirectAccess Troubleshooting TipsDirectAccess is a thing of beauty when everything is working as it should. When it isn’t, troubleshooting can be quite challenging. DirectAccess relies on many Windows platform technologies such as Active Directory for authentication, PKI for certificate management, group policy for settings deployment, IPsec for encryption, and IPv6 for transport. With so many dependencies, locating the source of the problem can be a difficult and daunting task.

I’m frequently called upon to help organizations of all sizes with DirectAccess troubleshooting. While this post is not intended to be a detailed, prescriptive guide for DirectAccess troubleshooting, I did want to share some common troubleshooting tips based on many years of troubleshooting DirectAccess.

Here are my top 5 DirectAccess troubleshooting tips:

  1. Check Prerequisites – Before diving in and collecting network traces and scouring event logs for clues as to why DirectAccess isn’t working, it’s essential to start at the beginning. Often the source of trouble is missing or misconfigured prerequisites. For example, is the DirectAccess client running a supported operating system? Remember, clients must be running Windows 10 Enterprise or Education, Windows 8.x Enterprise, or Windows 7 Enterprise or Ultimate. Also, ensure that the Windows firewall is enabled on DirectAccess servers and clients, that certificates are installed and valid (trusted, correct EKU, etc.), and that the DirectAccess settings GPO has been applied to servers and clients.
  2. Validate External Connectivity – If you are following implementation and security best practices for DirectAccess, the DirectAccess server will be in a perimeter/DMZ network behind an edge firewall. The firewall must be configured to allow inbound TCP port 443 only. If the firewall is also performing Network Address Translation (NAT), the NAT rule must be configured to forward traffic to the DirectAccess server’s dedicated or virtual IP address (VIP), or the VIP of the load balancer. Watch for routing issues when using load balancers too. It’s a good idea to confirm external connectivity using the Test-NetConnection PowerShell command. Even better, use the open source tool Nmap for more thorough testing.
  3. Remove Third Party Software – I can’t tell you how many times I’ve resolved DirectAccess connectivity issues by removing (not just disabling!) third party software on the client and/or server. It’s not uncommon for third-party security software to interfere with IPsec and/or IPv6 communication, both of which are vital to DirectAccess. If your DirectAccess troubleshooting efforts reveal no underlying issues with prerequisites or external connectivity, I’d suggest removing (at least temporarily) any third-party software and testing again.
  4. Isolate Environmental Issues – Occasionally other settings applied manually or via Active Directory group policy will interfere with DirectAccess. Examples include IPv6 being disabled in the registry, IPv6 transition technologies required to support DirectAccess are turned off, essential firewall rules for DirectAccess are disabled, or manipulating local security settings such as Access this computer from the network. To assist with troubleshooting it might be necessary to temporarily place DirectAccess clients and servers in their own dedicated Organizational Units (OUs) and block inheritance to isolate the configuration as much as possible. In addition, if DirectAccess clients are servers are provisioned using images or templates, testing with a clean build straight from the installation source (ISO or DVD) can be helpful.
  5. Check for Unsupported Configurations – If DirectAccess isn’t working, it might be possible the configuration you are trying to use is not supported. Examples including strong user authentication with OTP when force tunneling is enabled, provisioning Windows 7 clients when using Kerberos Proxy authentication, or provisioning Windows 10 clients when Network Access Protection (NAP) integration is enabled. These configurations won’t work and are formally documented here.

This is by no means a comprehensive or exhaustive troubleshooting guide. For more information and additional DirectAccess troubleshooting guidance I would encourage you to purchase my book Implementing DirectAccess with Windows Server 2016, which has an entire chapter devoted just to troubleshooting. In addition, watch my DirectAccess video training courses on Pluralsight for details and information about DirectAccess installation, configuration, management, support, and troubleshooting. And if you’re still struggling to resolve a DirectAccess problem, use the form at the bottom of this page to contact me to inquire about additional troubleshooting help.

Additional Resources

Microsoft Windows DirectAccess Client Troubleshooting Tool
DirectAccess and Windows 10 Professional
DirectAccess Troubleshooting with Nmap
DirectAccess Unsupported Configurations
Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book

Need assistance with DirectAccess troubleshooting? Complete the form below and I’ll get in touch with you.

SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP

From a client perspective, DirectAccess is an IPv6 only solution. It requires IPv6 connectivity from end-to-end to provide seamless, transparent, always-on remote access. DirectAccess clients are most commonly connected to the IPv4 Internet, so to overcome the limitations imposed by the exclusive use of IPv6 for transport, DirectAccess leverages IPv6 transition technologies such as 6to4, Teredo, or IP-HTTPS to tunnel IPv6 DirectAccess client communication over the IPv4 Internet. These transition protocols are favored by the operating system in the order in which I have listed them here. 6to4 uses IP protocol 41 for transport and requires that the client have a public IPv4 address, so if the DirectAccess client is behind a firewall that does not allow outbound IP protocol 41, or is located behind a NAT and has a private IPv4 address, it will fall back to Teredo. Teredo uses UDP for transport on port 3544, and if this communication is blocked by a firewall the DirectAccess client will then fall back to IP-HTTPS. IP-HTTPS, as its name implies, tunnels DirectAccess IPv6 traffic in HTTP, which is authenticated and encrypted using SSL or TLS.

Historically the challenge with the IP-HTTPS IPv6 transition protocol is that it encrypts DirectAccess communication which is already encrypted using IPsec. This double encryption places significant demands on CPU and memory resources on the DirectAccess server, resulting in poor throughput and performance and limiting the overall scalability of the solution. To address these shortcomings, Windows Server 2012 DirectAccess introduced support for IP-HTTPS NULL encryption. SSL/TLS is still used for authentication, but the IPsec traffic is no longer double encrypted. This dramatically reduces resource consumption on the DirectAccess server, resulting in improved performance and allowing many more DirectAccess clients to be handled by a single server. The only drawback is that IP-HTTPS NULL encryption is only supported with Windows 8 clients. When Windows 7 clients connect to a Windows Server 2012 DirectAccess server using IP-HTTPS, they will continue to use encrypted IP-HTTPS.

An ideal solution would be to terminate SSL off box using a dedicated hardware appliance like the F5 BIG-IP Local Traffic Manager (LTM). Unfortunately there is no provision in Windows Server 2012 DirectAccess to enable SSL termination for IP-HTTPS traffic. However, using some of the advanced features of the LTM, we can effectively offload SSL on the F5 by configuring LTM to emulate Windows 8 DirectAccess client behavior. This is accomplished by having the F5 LTM exclusively negotiate the use of a NULL encryption cipher suite with the Windows Server 2012 DirectAccess server on behalf of Windows 7 DirectAccess clients.

Note: This post assumes that you are familiar with the configuration and management of the F5 BIG-IP LTM solution, and that you’ve already imported your SSL certificates and configured nodes, pools, and virtual servers for your Windows Server 2012 DirectAccess server.

To configure the F5 LTM to provide SSL offload for Windows 7 DirectAccess clients, we’ll need to create SSL profiles to allow the use of specific cipher suites for our IP-HTTPS traffic. In its default configuration, the BIG-IP LTM does not support the use of NULL encryption cipher suites. Since Windows 8 DirectAccess clients use NULL cipher suites exclusively, we need to explicitly enable these on the LTM to support our Windows 8 clients. Since our Windows 7 clients will use only encrypted cipher suites, we’ll be sure to include those as well. To do this, open the F5 management console, expand Local Traffic, Profiles, SSL, and then click the green icon next to Client.


Provide a name for the new Client SSL Profile, select Advanced configuration, check the Custom box and specify DEFAULT:NULL for Ciphers. Be sure to select the appropriate SSL certificate and key. Click Finished at the bottom of the screen to save these settings. This change allows NULL cipher suites in addition to encrypted cipher suites, allowing us to support both Windows 8 and Windows 7 DirectAccess clients.


Next we need to configure the LTM to use only NULL cipher suites when communicating with the Windows Server 2012 DirectAccess server. To do this, expand Profiles, SSL, and then click the green icon next to Server.


Provide a name for the new Server SSL Profile, select Advanced configuration, check the Custom box and specify NULL-SHA for Ciphers. Click Finished at the bottom of the screen to save these settings. The end result here will be to force the exclusive use NULL encryption cipher suites for all IP-HTTPS traffic, regardless if it is a Windows 8 or Windows 7 client.


Once you’ve completed the client and server SSL profiles, it will be necessary to assign these profiles to the virtual servers that represent your Windows Server 2012 DirectAccess server. Navigate to Virtual Servers and click on Virtual Server List. Click the virtual server that corresponds to your DirectAccess server, and then scroll down to the bottom of the page. For SSL Profile (Client), select DA_IPHTTPS_CLIENT and add that to the list. Repeat this step for the SSL Profile (Server), this time selecting DA_IPHTTPS_SERVER. Click Update to apply these changes.


Once complete, the F5 BIG-IP LTM will now effectively be offloading SSL traffic on behalf of Windows 7 DirectAccess clients by emulating the Windows 8 DirectAccess client behavior and using only NULL encryption for IP-HTTPS sessions established with the Windows Server 2012 DirectAccess server. Although I can see no issues with this deployment model, be advised that this configuration may not be supported by Microsoft, so make these changes at your own risk. I’ll be working with Microsoft and F5 to get this solution reviewed and tested and I will provide clarification on supportability here once I have that information.

Special thanks to Jeff Bellamy, Ryan Korock, and John Wagnon at F5 for their assistance with this developing solution.

%d bloggers like this: