Performance issues with DirectAccess are not uncommon. In fact, there are numerous threads on Microsoft and third-party forums where administrators frequently complain about slow download speeds, especially when using the IP-HTTPS IPv6 transition technology. Based on my experience the problem does not appear to be widespread but occurs with enough regularity that it is worthy of further investigation.
DirectAccess Design
The inherent design of DirectAccess is a major limiting factor for performance. DirectAccess uses a complex and heavy communication channel, with multiple layers of encapsulation, encryption, and translation. Fundamentally it is IPsec encrypted IPv6 traffic, encapsulated in HTTP, and then encrypted with Transport Layer Security (TLS) and routed over IPv4. It is then decrypted, decapsulated, decrypted again, then converted back to IPv4. The high protocol overhead incurred with multiple layers of encapsulation, encryption, and translation result in increased packet fragmentation, which further reduces performance.
DirectAccess Performance
Even under the best circumstances, DirectAccess performance is limited by many other factors, most notably the quality of the network connection between the client and the server. DirectAccess performs reasonably well over high bandwidth, low latency connections. However, network performance drops precipitously as latency increases and packet loss is encountered. This is to be expected given the design of the solution.
Intermediary Devices
It is not uncommon to find intermediary devices like firewalls, intrusion detection systems, malware scanners, and other security inspection devices limit the performance of DirectAccess clients. In addition, many security appliances have bandwidth caps enforced in software for licensing restrictions. Further, incorrect configuration of inline edge devices can contribute to increased fragmentation, which leads to poor performance as well.
Slow Downloads over IP-HTTPS
Many people report that download speeds seem to be artificially capped at 355Kbps. While this seems to be a display bug in the UI, there is plenty of evidence to indicate that, in some scenarios, DirectAccess is incapable of high throughput even over high-quality connections. Some who have deployed DirectAccess and VPN on the same server have reported that download speeds are only limited when using DirectAccess over IP-HTTPS and not with VPN using Secure Socket Tunneling Protocol (SSTP), which also uses TLS. This has led many to speculate that the issue is either a bug or a design flaw in the IP-HTTPS tunnel interface itself.
TCP Window Scaling Issues
In some of the network traces I’ve analyzed I’ve seen evidence that seems to support this theory. For example, a network trace taken when downloading a file over DirectAccess with IP-HTTPS showed the TCP window never scaled beyond 64K, which would seriously impede performance. Interestingly this doesn’t seem to happy when the client uploads files over IP-HTTPS. Clearly something unusual is happening.
Microsoft KB Article
Microsoft recently released a vaguely-worded KB article that appears to lend credence to some of these findings. The article seems to acknowledge the fact there are known issues with DirectAccess performance, but it lacks any specific details as to what the root cause is. Instead, it simply advises migrating to Windows 10 Always On VPN.
Summary
DirectAccess IP-HTTPS performance issues don’t appear to affect everyone, and the problem only seems to apply to file downloads and not to other types of traffic. However, there is mounting evidence of a systemic issue with DirectAccess performance especially over IP-HTTPS. Customers are advised to closely evaluate their uses cases for DirectAccess and if remote clients are frequently required to download large files over a DirectAccess connection, an alternative method of file transfer might be required. Optionally customers can consider evaluating alternative remote access solutions that offer better performance such as Windows 10 Always On VPN or third-party solutions such as NetMotion Mobility.
Additional Resources
Always On VPN and the Future of DirectAccess
What’s the Difference Between DirectAccess and Always On VPN?
NetMotion Mobility as an Alternative to Microsoft DirectAccess
sternjoe92
/ February 20, 2018One specific thing to look at while diagnosing this problem: if you have a Sophos UTM, try disabling UDP Flood protection.
Richard M. Hicks
/ February 20, 2018Thanks for the tip Joe! 🙂
Bryan James
/ June 2, 2020Any reason why clients will intermittently get disconnected from directaccess. How can I check what causes it? This affects all the clients and there is no problem with both the internet.
Richard M. Hicks
/ June 4, 2020This could be caused by any number of things. If it is affecting all clients, I would suspect that perhaps a service might be crashing on the DirectAccess server, or perhaps a network device inline is failing intermittently. Again, I’m assuming the issue happens to all users at the same time. If not there may be other considerations.
Bryan James
/ June 4, 2020Hi Richard,
Thank you for the response. The thing is… it affects all clients yes but at different intervals. That’s why it is so puzzling. Event viewer > System did not show me anything that is crashing. The networks on both server and clients haven’t dropped a ping in terms of network connectivity but only dropped for DirectAccess. The DirectAccess server is on Azure btw.
Richard M. Hicks
/ June 8, 2020If it was something on the server side I’d expect it to affect all clients at the same time. If it is happening to clients individually I’d suspect something on the client itself, or something in the path between the client and server (e.g. client’s firewall, router, or ISP).
Jon Williams
/ December 16, 2020this is the bane of my existance at present with COVID restrictions in the UK, intermittent client issues,
I have found that bringing the device back to work, removing from the OU and making sure membership of the DA has been revoked.
GPupdate a few times to make sure GP has applied of the new OU.
Add back into DA OU make sure membership has been attributed to the Device in AD, then GPUPDATE a few hundred times (lol) and then wait to see if youre presented with “waiting for workplace connectivity” on start up seems to resolve it temporarily.
However though I am also finding that those people with Much slower ISP services are struggling even further.
Does anyone know of there is a min MBPS for home connections to be able to be stable on DA?
Bryan James
/ June 4, 2020also; i don’t know if this is related, i see the following error after every disconnection from the client.
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed.
Richard M. Hicks
/ June 8, 2020I see those pretty commonly and believe they are anomalous. I’d suggest taking a network trace on the client and the server and comparing them. That would give you some clue as to who initiate the disconnect.