If you’ve ever attended one of our “DirectAccess: Best Practices” webinars, or read anything that I have written regarding the DirectAccess transition technologies, you know I am an absolute advocate of keeping Teredo enabled whenever possible. The premise for this recommendation is simple: improved performance. There are a number of different possible client/server combinations in a DirectAccess connection, and depending on what combination is used, you may or may not be running as efficiently as possible. I come across many DirectAccess implementations in the wild that were configured in a way where Teredo is disabled, and so all client connections are being made via the IP-HTTPS transition tunnel. Technically this is fine, as all clients are able to make IP-HTTPS connections, but depending on what operating systems you are running, you may be double-encrypting every packet that flows in or out of every DirectAccess client computer. This makes for slower connections on the client side, and heavier resource utilization on the server side, resulting in slower speeds and fewer users that you can squeeze onto that DA server.
To give a little background, the reason your traffic might be doubly encrypted is because all DirectAccess traffic is encrypted with IPsec all the time. In addition to that encryption, when certain operating system combinations are in effect in a DA connection, your IP-HTTPS tunnel might also be encrypting that traffic stream a second time with TLS. Think of it this way, your transition tunnel (Teredo or IP-HTTPS) is like a conduit flowing through a wall. Inside that conduit run your individual networking cables, which are akin to your DirectAccess IPsec tunnels. Your IPsec tunnels that flow inside the conduit are already encrypted, so there is no need to encrypt the conduit itself. However, that is exactly what IP-HTTPS does in many circumstances. This is the core reason why we keep Teredo enabled when possible, so that any users which can connect using Teredo do so, and lessen the encryption processing load on both the clients and the DirectAccess servers. Here are some examples of IP-HTTPS connections that will help to show in what cases you are experiencing double encryption:
Client/Server operating system combinations when connecting via IP-HTTPS:
Windows 7 / UAG DirectAccess: Yes, double encryption.
Windows 7 / 2012 DirectAccess: Yes, double encryption.
Windows 8 / UAG DirectAccess: Yes, double encryption.
Windows 8 / 2012 DirectAccess: No, only the IPsec encryption is happening here, at least in most cases.
In the event that your client computer is running Windows 8 or higher, and the DirectAccess server is running Server 2012 or higher, then we are finally in a position where the negotiations of the tunnel are smart enough to negotiate null encryption on the IP-HTTPS tunnel itself. Because all DirectAccess traffic is already secured inside IPsec, we can safely negotiate NULL, and take some of the processing load for the IP-HTTPS tunnel off the client and the server. This is great news, and as the newer operating systems roll out further and further, this will help to speed up DA connections and reduce the load on DA servers everywhere!
BUT…there’s a catch, which is the purpose of this article. If you enable some of the advanced features on your Server 2012 DirectAccess server, namely VPN or OTP, your NULL encryption negotiation option will be gone. There is nothing in the wizards or GUI which tells you this is going to happen, but as soon as you enable OTP or add the VPN role to a DirectAccess server, the ability for your IP-HTTPS tunnels to connect using NULL vanishes, and all of your IP-HTTPS connections, even those between Windows 8 and Server 2012, are always double encrypted. This happens namely because you don’t want OTP credentials which are used as part of the IPsec tunnel authorization to be sent clear-text across the internet, and if you have users connecting via SSTP VPN, same is true. You certainly wouldn’t want their VPN tunnels to be able to authenticate and pass credentials over that null stream, sending critical information via clear text across the internet.
So while NULL encryption for IP-HTTPS tunnels gets disabled for very good reasons, the fact that this happens is not advertised anywhere for the administrator to see, and so you may be caught off guard to find that you have enabled VPN only to experience higher CPU load on your DA server, or complaints from users about having slightly slower connections than they used to have.
Microsoft MVP | Enterprise Security