DirectAccess IP-HTTPS Null Encryption and SSTP VPN

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.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

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.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

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.

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.

Leave a comment

12 Comments

  1. Robert

     /  July 11, 2014

    Hi! You write

    “disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely”

    but how do I remove the VPN role? I cant see the NULL ciphers when checking DA address at http://www.ssllabs.com even though I clicked “Disable VPN” in the Remote Access Management Console (which says that the VPN will be removed).

    /Robert

    Reply
    • Hi Robert. Sorry for the late reply. During my initial testing removing VPN support returned the NULL cipher suites in my test lab. I’ll test again just to confirm though.

      Reply
      • Robertr

         /  July 20, 2014

        Hi Richard! I noticed that it took a couple of days Before the cache att ssllabs was completely flushed, when I ran the test a couiple of days later the NULL cipher suite was there, as expected. Thanks for the reply!
        /Robert

      • Good to hear. Thanks for following up.:)

  2. Mark Ringo

     /  July 24, 2014

    Interesting article. I’m trying to optimize my performance for DirectAccess clients and was happy to see this article since my DirectAccess servers run both Client VPN and DA. When I execute the test on ssllabs.com against my servers it shows exactly Figure 1 (with Null Encryption in red). I was not expecting this result since the servers run both types of VPN. My pair of NLB DA servers are well-provisioned Hyper-V VMs and my service is 45 MBit synchronous. The very best that I can get is 12 MBit on the interface and only for a moment (the average is about 5). How would you go about resolving this performance problem? Thanks for any help.

    Reply
    • That’s unusual. I wouldn’t expect to see NULL encryption cipher suites offered if client-based VPN is also configured on the same server. Perhaps there is a scenario in which this is allowed that I haven’t tested yet? I’ll definitely look in to it. Regarding performance, it’s difficult to state why performance is less than expected. However, IPsec network processing is likely the culprit, especially in a virtual environment. The hypervisor in this scenario imposes a pretty steep performance penalty. You would probably see much better performance using a dedicated server.

      Reply
  3. ryan phillips

     /  August 6, 2014

    I have setup DA 2012 R2 and not configured the vpn role. When I do the SSL test I am receiving the following back.

    Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites always at the end)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits (p: 128, g: 128, Ys: 128) FS 256
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits (p: 128, g: 128, Ys: 128) FS 128
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128

    nothing about Null and a lot less entries then either of your images show. I’m noticing extremely slow speeds to a windows 8.1 ENT machine when both are connected to 1gb connections (I see 1mb/s) Any ideas on how to enable Null ciphers or any idea on how to speed things up?

    Reply
  1. Direct Access + Network Access Protection – part 1 – Introduction
  2. DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites | Richard Hicks' DirectAccess Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 44 other followers

%d bloggers like this: