Share via

DirectAccess Client Connection is Slow

  • Article

Updated: November 18, 2009

Applies To: Windows Server 2008 R2

DirectAccess performance is dependent on many factors such as the speed of the DirectAccess client’s connection to the Internet, Internet latency and congestion between the DirectAccess client and server, and the current load on the DirectAccess server. Another reason might be the type of Internet Protocol version 6 (IPv6) encapsulation being used over the Internet Protocol version 4 (IPv4) Internet. 6to4 and Teredo tend to have higher performance because the encapsulation is simpler to process. Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) tends to have lower performance because of the higher protocol overhead and the additional Secure Hypertext Transfer Protocol (HTTPS)-based encryption and decryption. When examining performance issues, one of the first places to look is the display of the ipconfig command on the DirectAccess server, which indicates the type of encapsulation based on the interface that has a global IPv6 address assigned.

A DirectAccess client on a private IPv4 network behind a network address translator (NAT) must connect to the DirectAccess server using either Teredo or IP-HTTPS. Each of these transition technologies requires particular types of traffic between the DirectAccess client and the DirectAccess server:

  • Teredo requires IPv4 and User Datagram Protocol (UDP) destination port 3544 for traffic to the two public IPv4 addresses of the Teredo server and relay (the DirectAccess server). The Teredo relay requires Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request and Echo Reply messages to be allowed for all intranet destinations, including the DirectAccess server.

  • IP-HTTPS requires IPv4 and Transmission Control Protocol (TCP) destination port 443 traffic between the DirectAccess client and the first consecutive public IPv4 address of the DirectAccess server.

The DirectAccess client needs to determine which of these two transition technologies to use. IP-HTTPS and Teredo both attempt qualification of their interface state at the same time. If the Teredo interface is qualified, the IP-HTTPS client waits in an offline state for a computed delay for the DirectAccess client to detect corporate connectivity. The computed delay is either ten seconds or a network delay larger than ten seconds based on the round trip time of TCP packets from the client to the public IPv4 address of the DirectAccess server. If the DirectAccess client detects corporate connectivity within this network delay, the IP-HTTPS client will remain in an offline state. If the DirectAccess client does not detect corporate connectivity within this network delay, the IP-HTTPS client will attempt to qualify again.

Using IP-HTTPS for DirectAccess connectivity has higher overhead and lower performance than Teredo. If the DirectAccess client is using IP-HTTPS instead of Teredo, the DirectAccess client will have a lower performance connection.

However, due to network timing issues, it is possible for the DirectAccess client to have both Teredo and IP-HTTPS interfaces active, but use only the IP-HTTPS interface for traffic to the intranet. This condition occurs when the DirectAccess client takes more than the computed delay for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test for this condition, run the ipconfig command at a command prompt. If you have global addresses on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.