An important scalability improvement introduced in Windows Server 2012 DirectAccess is the support for null encryption for Windows 8.x DirectAccess clients using the IP-HTTPS IPv6 transition protocol. Using null encryption eliminates the overhead imposed by the needless encryption of DirectAccess IPsec communication, which itself is already encrypted. This double encryption significantly increases resource consumption on both the client and server, and can have a negative impact on scalability and performance. When a Windows 8.x client establishes an IP-HTTPS connection to a Windows Server 2012 or 2012 R2 DirectAccess server, it will negotiate only cipher suites that use null encryption. Windows 7 clients cannot take advantage of null encryption and continue to use encrypted cipher suites.

Note: It is possible to replicate some of the benefits of null encryption for Windows 7 clients using an Application Delivery Controller (ADC) such as the F5 Networks Local Traffic manager (LTM) to perform SSL offloading. See SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP for more information.

For both performance and scalability, the best deployment results are achieved when using a Windows Server 2012 or 2012 R2 DirectAccess server and Windows 8.x clients. However, null encryption for IP-HTTPS is no longer available in the scenario where client-based remote access VPN is configured on the same server as DirectAccess. As you can see below, when DirectAccess is deployed by itself, the server offers null encryption cipher suites which Windows 8.x clients can take advantage of.

Figure 1 – Cipher Suites for DirectAccess Only

However, when the client-based remote access VPN role is enabled on the same DirectAccess server, null encryption cipher suites are no longer available for use by DirectAccess clients.

Figure 2- Cipher Suites for DirectAccess and VPN

This occurs because the Secure Sockets Tunneling Protocol (SSTP) client-based remote access VPN protocol requires SSL/TLS encryption to provide confidentiality for tunneled network communication. Unfortunately, disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely. Of course none of this is readily apparent to the administrator, who may be completely unaware that they’ve sacrificed the efficiency of IP-HTTPS null encryption for Windows 8.x clients in order to support SSTP for client-based remote access VPN clients.

Note: There are additional scenarios in which null encryption for Windows 8.x DirectAccess clients is not supported. For example, if you enable the Web Application Proxy (WAP) role on the DirectAccess server, or if you configure DirectAccess to use one-time password (OTP) authentication, null encryption support is lost for Windows 8.x clients.

If you plan to support Windows 8.x clients using IP-HTTPS and want to take full advantage of the scalability and performance benefits associated with IP-HTTPS null encryption in Windows Server 2012/R2 DirectAccess, it is recommend that you deploy client-based remote access on a separate system.