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.

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.

Leave a comment


  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 even though I clicked “Disable VPN” in the Remote Access Management Console (which says that the VPN will be removed).


    • 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.

      • 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!

      • 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 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.

    • 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.

  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?

  4. Dev Ramdin

     /  December 30, 2014

    Hi Richard,

    I’ve discovered than when OTP is enabled the NULL cipher suites are also no longer available. Do you know if that is by design?


    • Absolutely. We don’t want credentials passed in the clear, which is why NULL cipher suites aren’t supported when client-based VPN is enabled. :)

  5. Phil

     /  January 15, 2015

    Hi Richard

    We have exactly the same scenario as Ryan Phillips. We are using Windows Server 2012 R2 using a generic out of the box installation of Direct Access (without VPN), which created and used its own self signed certificate.

    We have tried the suggested articles (SCHANNEL Registry etc) but the SSL Labs report only ever displays the same 6 cipher suites that Ryan reported.

    Do you have and other ideas what could be causing this issue? Clients can connect and use DA successfully, but the performance is disappointing.


    • That certainly is unusual, and I’ve not encountered that in my testing. I have to assume that something is unique with your configuration that I’m overlooking. Also, keep in mind that when you repeat the SSL Labs test, be sure to click “clear cache” to complete run another test, otherwise it will report the results from your last test and now show any changes that you might have made. I’ve been bitten by that in the past. :)

      • Phil

         /  January 20, 2015

        Thanks for taking the time to reply Richard, your clear cache advice is certainly a good one to remember but in our case we had already found that option.

        Following your post I decided to go back to basics, I created a new test Windows 2012 R2 server in our test lab, applied no updates and just performed a Direct Access simple installation using the getting started Wizard. I then assigned the server a public IP address stuck it on the internet and tested on SSL labs, again we only had the 6 ciphers available that Ryan originally posted. To eliminate that the problem could be caused by Windows Server 2012 R2 I performed the same test but this time on Windows Server 2012, in this instance you only get 3 ciphers available.

        My next thought was perhaps the issue was caused by the self signed certificate which is automatically created as part of the install. So I went back to my test 2012 R2 box and applied our godaddy wildcard SSL certificate to the server, assigned it to DirectAccess and performed the test again (this was without “tweaking” any of the SCHANNEL registry keys – just left default) and this appears to have solved our problem. The NULL ciphers now appear.

      • Thanks for following up! I don’t ever use the “simple” DirectAccess deployment with self-signed certificates, so I’ve never encountered that issue. It’s definitely good information to know, so thanks for sharing. Yet another reason not to use self-signed certificates! :)

  6. Gary

     /  April 2, 2015

    Hi Richard,

    Can you clarify, on the Qualys SSL test, our DA server does indeed show the 2 NULL encryption suites


    now, as I understand it, this is actually desirable for a direct access URL as in windows 8.1 as it is utilised to avoid double encryption. However, testing your direct access will always net an F rating on this site due to these 2 cipher suites. Provided the rest of our results are up to snuff, we can safely ignore this warning right?

    • That’s correct. A dedicated DirectAccess server (without VPN installed) that doesn’t have OTP authentication configured will always receive an “F” rating from the Qualys SSL Labs test site. This happens, as you noticed, because in this configuration DirectAccess makes use of cipher suites that use null encryption. This is done to eliminate the protocol overhead of double encryption for Windows 8.x and later DirectAccess clients using the IP-HTTPS IPv6 transition protocol. It’s important to remember that the SSL Labs server test is designed expressly for web servers. DirectAccess is a unique workload that uses HTTPS purely as a tunneling mechanism for IPv6 traffic, which of course the SSL Labs test isn’t aware of. Obviously not using encryption on a web server is probably a bad thing, but for DirectAccess it’s ok because the payload is already encrypted.

      • Hello there, we have the same problems here, crazy thing is, that one of our 2 Windows 8.1 machines can connect without any problem, no error messages in server eventlog. The new client cannot connect, causing the 36888 and 36874 ids in the system log of the server.
        This is the result of the SSL Test, no NULL cipher visible.

        The question is, why can 1 client connect and the other not? The working client has an older client certificate, may that be the reason?

        THanks in advance, Marcus

        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 WEAK 256
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits (p: 128, g: 128, Ys: 128) FS WEAK 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

      • If one client can successfully connect, you know that the server is configured correctly. I’d look closely at the configuration of the client. Correct SKU? Certificates in place? Were the DirectAccess GPO settings applied? I expect you’ll find something missing on the client side somewhere.

  7. Hello Richard, Windows is 8.1 Enterprise, certificates in place. The Client connects for a couple of seconds but then disconnects again, leaving the error Messages in the System log and some 4653 Errors in the security log. Checked everything, even reinstalled the Client, also with Windows 10 Enterprise, still same error… freaking out.

    • Puzzling, but I still suspect something on the client side, as you stated previously that you have some clients connecting successfully. You may need to gather additional information using detailed event logging to netsh tracing. It might be best to open a support case with Microsoft so they can assist in gathering this information and interpreting it for you.

  8. Great post Richard. We currently have VPN and DA on the same server and have a multi-site configuration. I have a few questions:
    1) How can I remove the VPN role, but keep DA intact?
    2) Since we’re using a multi-site configuration, a subca or rootca cert is required. Our current cert is sha-1/rsa and works just fine. We’re in the process on migrating to a new PKI which is sha256/ecc. From the testing I’ve done, the IPSEC connection is failing with the new SubCA cert inplace. Do you know if ECC is supported for the SubCA/RootCA cert?

    • You should be able to remove client-based VPN and leave DirectAccess intact by issuing the following PowerShell command – Uninstall-RemoteAccess -VpnType VPN.

    • SHA265 work just fine, but ECC is not natively supported for DirectAccess unfortunately. :/

  1. Direct Access + Network Access Protection – part 1 – Introduction
  2. DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites | Richard Hicks' DirectAccess Blog
  3. DirectAccess IPv6 Transition Protocols Explained | Richard Hicks' DirectAccess Blog
  4. Disable 6to4 IPv6 Transition Protocol for DirectAccess Clients | Richard Hicks' DirectAccess Blog

Leave a Reply

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

You are commenting using your 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


Get every new post delivered to your Inbox.

Join 85 other followers

%d bloggers like this: