SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP

From a client perspective, DirectAccess is an IPv6 only solution. It requires IPv6 connectivity from end-to-end to provide seamless, transparent, always-on remote access. DirectAccess clients are most commonly connected to the IPv4 Internet, so to overcome the limitations imposed by the exclusive use of IPv6 for transport, DirectAccess leverages IPv6 transition technologies such as 6to4, Teredo, or IP-HTTPS to tunnel IPv6 DirectAccess client communication over the IPv4 Internet. These transition protocols are favored by the operating system in the order in which I have listed them here. 6to4 uses IP protocol 41 for transport and requires that the client have a public IPv4 address, so if the DirectAccess client is behind a firewall that does not allow outbound IP protocol 41, or is located behind a NAT and has a private IPv4 address, it will fall back to Teredo. Teredo uses UDP for transport on port 3544, and if this communication is blocked by a firewall the DirectAccess client will then fall back to IP-HTTPS. IP-HTTPS, as its name implies, tunnels DirectAccess IPv6 traffic in HTTP, which is authenticated and encrypted using SSL or TLS.

Historically the challenge with the IP-HTTPS IPv6 transition protocol is that it encrypts DirectAccess communication which is already encrypted using IPsec. This double encryption places significant demands on CPU and memory resources on the DirectAccess server, resulting in poor throughput and performance and limiting the overall scalability of the solution. To address these shortcomings, Windows Server 2012 DirectAccess introduced support for IP-HTTPS NULL encryption. SSL/TLS is still used for authentication, but the IPsec traffic is no longer double encrypted. This dramatically reduces resource consumption on the DirectAccess server, resulting in improved performance and allowing many more DirectAccess clients to be handled by a single server. The only drawback is that IP-HTTPS NULL encryption is only supported with Windows 8 clients. When Windows 7 clients connect to a Windows Server 2012 DirectAccess server using IP-HTTPS, they will continue to use encrypted IP-HTTPS.

An ideal solution would be to terminate SSL off box using a dedicated hardware appliance like the F5 BIG-IP Local Traffic Manager (LTM). Unfortunately there is no provision in Windows Server 2012 DirectAccess to enable SSL termination for IP-HTTPS traffic. However, using some of the advanced features of the LTM, we can effectively offload SSL on the F5 by configuring LTM to emulate Windows 8 DirectAccess client behavior. This is accomplished by having the F5 LTM exclusively negotiate the use of a NULL encryption cipher suite with the Windows Server 2012 DirectAccess server on behalf of Windows 7 DirectAccess clients.

Note: This post assumes that you are familiar with the configuration and management of the F5 BIG-IP LTM solution, and that you’ve already imported your SSL certificates and configured nodes, pools, and virtual servers for your Windows Server 2012 DirectAccess server.

To configure the F5 LTM to provide SSL offload for Windows 7 DirectAccess clients, we’ll need to create SSL profiles to allow the use of specific cipher suites for our IP-HTTPS traffic. In its default configuration, the BIG-IP LTM does not support the use of NULL encryption cipher suites. Since Windows 8 DirectAccess clients use NULL cipher suites exclusively, we need to explicitly enable these on the LTM to support our Windows 8 clients. Since our Windows 7 clients will use only encrypted cipher suites, we’ll be sure to include those as well. To do this, open the F5 management console, expand Local Traffic, Profiles, SSL, and then click the green icon next to Client.

f5_directaccess_iphttps_offload_01

Provide a name for the new Client SSL Profile, select Advanced configuration, check the Custom box and specify DEFAULT:NULL for Ciphers. Be sure to select the appropriate SSL certificate and key. Click Finished at the bottom of the screen to save these settings. This change allows NULL cipher suites in addition to encrypted cipher suites, allowing us to support both Windows 8 and Windows 7 DirectAccess clients.

f5_directaccess_iphttps_offload_02

Next we need to configure the LTM to use only NULL cipher suites when communicating with the Windows Server 2012 DirectAccess server. To do this, expand Profiles, SSL, and then click the green icon next to Server.

f5_directaccess_iphttps_offload_03

Provide a name for the new Server SSL Profile, select Advanced configuration, check the Custom box and specify NULL-SHA for Ciphers. Click Finished at the bottom of the screen to save these settings. The end result here will be to force the exclusive use NULL encryption cipher suites for all IP-HTTPS traffic, regardless if it is a Windows 8 or Windows 7 client.

f5_directaccess_iphttps_offload_04

Once you’ve completed the client and server SSL profiles, it will be necessary to assign these profiles to the virtual servers that represent your Windows Server 2012 DirectAccess server. Navigate to Virtual Servers and click on Virtual Server List. Click the virtual server that corresponds to your DirectAccess server, and then scroll down to the bottom of the page. For SSL Profile (Client), select DA_IPHTTPS_CLIENT and add that to the list. Repeat this step for the SSL Profile (Server), this time selecting DA_IPHTTPS_SERVER. Click Update to apply these changes.

f5_directaccess_iphttps_offload_05

Once complete, the F5 BIG-IP LTM will now effectively be offloading SSL traffic on behalf of Windows 7 DirectAccess clients by emulating the Windows 8 DirectAccess client behavior and using only NULL encryption for IP-HTTPS sessions established with the Windows Server 2012 DirectAccess server. Although I can see no issues with this deployment model, be advised that this configuration may not be supported by Microsoft, so make these changes at your own risk. I’ll be working with Microsoft and F5 to get this solution reviewed and tested and I will provide clarification on supportability here once I have that information.

Special thanks to Jeff Bellamy, Ryan Korock, and John Wagnon at F5 for their assistance with this developing solution.

Leave a comment

31 Comments

  1. Christian R

     /  July 11, 2013

    I do understand the benefit of this from an F5 perspective but what is the real benefit of moving CPU cycles from DA to F5? Is a CPU cycle cheaper on F5?

    Reply
    • Yes, much cheaper. 🙂 The F5 appliance is a dedicated, purpose-built platform that can perform SSL encryption much more quickly and efficiently than a general purpose server. By letting the F5 perform the SSL functions we can save CPU and memory resources on the DirectAccess server and scale much more effectively.

      Reply
      • When compared to putting a cavium card in the server, using F5 is a far more expensive option if you need to buy kit. Christian was asking about price, not performance.

      • Good point. If you’re talking about a green field deployment, using a Cavium card in the DirectAccess server is going to be much less expensive than the F5 option. However, in my experience, the performance provided by Cavium crypto accelerators *on Windows machines* is less than optimum. The F5 alternative, while perhaps costing more, will most likely yield much better benefits in this area.

  2. Hello Richard,
    My company does not want to expose the TCP port 443 of a domain server (the direct access server) to the whole internet community, and ask me to setup a peripheral pre-authentication on edge f5, so that only corporate PC’s with a value pki certificats could get in touch with the DA server. Do you think client PCs could be forced to show their computer cert to the f5 at the establishment or a 2-way authenticated iphttps transport session? Without disturbing DA server session setup? Any f5-related référence to suggest?

    Reply
    • Something like that might be possible using iRules on the F5, but I’m not certain. If you come up with something, let me know. 🙂

      Reply
      • Delbecq Bernard

         /  March 25, 2014

        Hi Richard,

        In the meantime, I succeeded into intercepting the SSL transport traffic at f5 level, so that f5 forces the Win7 PC to present its machine certificate in order to “pre-authenticate” the SSL session before getting further to the DirectAccess server.
        F5 requests a certificate trusted by the internal enterprise MS PKI by enabling the SSL client profile authentication tab. Still no script, only SSL profile configuration. But, as we are paranoiac, the certificate presented is further analyzed by an f5 iRule (script) that exacts the certificate issuer and checks its DN against the MS PKI CA DN name, to avoid a hacker would try to get in by forcing an unsuited certificate.
        The f5 to DirectAccess session is not encrypted, nor authenticated, at least at SSL level, but re-uses the “NULL cipher” WIN8 behavior you described in your blog article.

        Of course, f5 does not touch the IPsec/AuthIp traffic carried by the SSL tunnel, so the DA server continues to think it’s directly in touch with the requesting client, and can normally authenticate/log the correct PC number.

        No change at DA client nor at DA server; in fact no change in any Microsoft component.

        This way, the DA server TCP port 443 is effectively shielded from the whole Internet community, and only exposed to the previously authenticated corporate PC, which was the mandatory requirement in order to improve in “defense in depth” and “multi-vendor security controls”.

        A penetration test conducted by an external ethical hacking company confirmed that the DA server just does not receive one byte until successful pre-authentication by the BigIp.

        We have filed an advisory case at Microsoft in order to confirm that this behavior can be officially supported –or not? All in all, what we ask is that the SSL client session setup continues to support the presentation of a PKI certificate when requested by the connected SSL server, which is not so difficult to maintain…

        Thanks one more for your blog article, that drove me in the correct direction, and convinces me that it could be possible. Yes, we can…

  3. Hamilton

     /  June 9, 2014

    Hi RIchard,
    Thanks for your article, any information on how to have an already setup DA server load balance with the F5? Or even translate through an F5?

    Reply
    • No, I don’t. I’m not an F5 expert, so I provide the offloading information because they pertains to DirectAccess. You’ll have to look at the F5 web site for more details on general load balancing for DirectAccess.

      Reply
  4. Thomas

     /  July 2, 2014

    Hi Richard,
    Inserting the BigIP in front of the DA server effectively offloads the SSL processing for it, but does not help the Windows 7 clients, which would continue the “double encryption”…
    Would it be possible to fix the root cause by somehow manipulating the Windows 7 client into using the NULL encryption cypher suite for the DA connections?
    Thanks for the article,
    Toma

    p.s. I think you need to switch over the client and the server profiles in your F5 example above.

    Reply
    • That’s correct. Windows 7 clients still suffer from the double encryption liability using this configuration. However, it is quite typical that clients have enough surplus processing power that it doesn’t adversely affect operation, in most cases. The real challenge is on the server side, where potentially thousands of DirectAccess clients are connected. That’s when using the F5 to offload SSL encryption greatly reduces the load on the server and improves scalability significantly.

      Also, there is no way, to my knowledge, to configure the client to use NULL encryption for SSL/TLS. It’s an architectural limitation of the Windows 7 client.

      Regarding the client and server SSL profile configuration in the examples, those are correct. In this case, the F5 is acting as a “client” to the DirectAccess server and is configured only to use NULL encryption. It acts as a “server” for the DirectAccess clients and there for is configured to accept both NULL encryption for Windows 8 clients in addition to the standard encrypted cipher suites to also support windows 7 clients.

      Reply
  5. xcomiii

     /  November 1, 2014

    Hi Richard and thanks for you excellent blog on DA.

    Is there any news on support of this configuration from either Microsoft or F5? I am in the design phase of a new DA setup and will be using F5, and I also need to support both Win7 and Win8 clients, including ManageOut. So when I found this article, I got interested to see if I should implement your configuration here. But of course, I wonder if this is officially supported. I do have access to top experts from F5 Partners. Thanks!

    Reply
    • I’ve had discussions with the Microsoft product team and their stance it that this is neither supported or unsupported. Essentially you can use a load balancer however you see fit, and they will continue to support DirectAccess. However, if a support engineer believes that the load balancer configuration may be affecting DirectAccess functionality, they may ask you to remove it for testing purposes. They may also ask that you engage your load balancer manufacturers support organization to provide assistance.

      Reply
  6. Calliper

     /  December 18, 2014

    I’ve offloaded SSL to F5 (BIG-IP 4000S units) using the steps in this blog. We saw 56% improvement in large-file copy performance, but small-file copy performance was much, much worse – only a quarter the speed. Ping latency to a domain controller took nearly three times as long. In short, not worth the trouble. Perhaps why this guidance is neither on F5 nor Microsoft’s websites.

    Reply
    • Interesting feedback, and thanks for sharing that data! No doubt there are tradeoffs when offloading SSL with an ADC. A common problem I see with this is that it disrupts receive-side scaling on the DirectAccess server if the traffic appears to source from the ADC and not the client. You may have saved some CPU cycles on the DirectAccess server, but then scalability is impacted because all CPU cores can’t be used for processing network traffic. :/

      Reply
  7. Richard,
    Your articles on DA have been very helpful and instrumental in assisting me to get up and running. I have a functional, (supposedly) install and want to test on the outside. Very little documentation on what ports on the firewall to open, other than: https://technet.microsoft.com/en-us/library/jj134204.aspx?f=255&MSPPError=-2147217396#ConfigFirewalls.
    I plan on using a Netscaler to offload the SSL. Since Netscaler seems to be the load balancer of choice for so many MS products I thought I would find some stuff on it, but I didn’t.
    Have anything you can share regarding the 2 items above?

    Thanks,
    Ian

    Reply
    • Hi Ian,

      Thanks for the kind words. 🙂 The firewall configuration when the DirectAccess server is behind a NAT or load balancer is pretty straightforward – inbound TCP port 443. I’ve not had the opportunity to work with the Netscaler to load balance DirectAccess, but I hope to in the near future. I’m sure I’ll have something to share on the blog when that happens.

      Reply
      • Thanks for the quick response. OK, so just 443 is simple enough. Now, how does the client find the network from the outside? I assume something is baked into GP an IP or A record, but I can’t find where.

      • Using the public hostname. For IP-HTTPS, you can see this with Get-NetIPHTTPSConfiguration or netsh interface httpstunnel show interface.

  8. Richard,
    There is little mention of a CRL Distribution Point for Certificates in most guides and you never mention it either. Is it NOT required? My implementation still is not functional despite having all green checkmarks in the GUI so I’m trying to figure out what I am missing. Client side troubleshooting is very limited and I don’t know where its breaking down.

    Ian

    Reply
    • Hi Ian,

      It depends on which certificate you are talking about. By default, the computer certificates used for IPsec don’t require a CRL (unless you’ve specifically changed this policy). For the SSL certificate used for IP-HTTPS, the CRL is only required for Windows 7 clients. Windows 8/10 clients don’t check the CRL for IP-HTTPS. If you’re using a public CA for the IP-HTTPS certificate, you don’t have to worry about it. If you’re using a certificate issued by your internal private PKI and you plan to support Windows 7 clients, then the CRL will have to be available publicly.

      Hope that helps! 🙂

      Reply
  1. DirectAccess and NAT | Richard Hicks' DirectAccess Blog
  2. Windows Server 2012 DirectAccess IP-HTTPS and Windows 7 Clients | Richard Hicks' DirectAccess Blog
  3. DirectAccess IP-HTTPS Null Encryption and SSTP VPN | Richard Hicks' DirectAccess Blog
  4. DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites | Richard Hicks' DirectAccess Blog
  5. Some new DirectAccess unsupported scenarios - Simple and secure by Design but Business compliant [Benoît SAUTIERE / MVP]
  6. DirectAccess IPv6 Transition Protocols Explained | Richard Hicks' DirectAccess Blog
  7. DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP | Richard Hicks' DirectAccess Blog
  8. DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler | Richard Hicks' DirectAccess Blog
  9. DirectAccess IP-HTTPS Error 0x2af9 | 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

%d bloggers like this: