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.
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.
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.
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.
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.
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.
Christian R
/ July 11, 2013I 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?
Richard Hicks
/ July 11, 2013Yes, 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.
Rowan Harris
/ February 18, 2014When 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.
Richard Hicks
/ February 24, 2014Good 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.
Bernard Delbecq
/ March 11, 2014Hello 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?
Richard Hicks
/ March 24, 2014Something like that might be possible using iRules on the F5, but I’m not certain. If you come up with something, let me know. 🙂
Delbecq Bernard
/ March 25, 2014Hi 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…
Hamilton
/ June 9, 2014Hi 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?
Richard Hicks
/ June 22, 2014No, 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.
Thomas
/ July 2, 2014Hi 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.
Richard Hicks
/ July 3, 2014That’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.
xcomiii
/ November 1, 2014Hi 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!
Richard Hicks
/ November 3, 2014I’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.
xcomiii
/ November 3, 2014Great, thanks for your reply!
Calliper
/ December 18, 2014I’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.
Richard Hicks
/ December 20, 2014Interesting 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. :/
Ian Fischer
/ December 11, 2015Richard,
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
Richard M. Hicks
/ December 11, 2015Hi 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.
Ian Fischer
/ December 14, 2015Thanks 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.
Richard M. Hicks
/ December 14, 2015Using the public hostname. For IP-HTTPS, you can see this with Get-NetIPHTTPSConfiguration or netsh interface httpstunnel show interface.
Ian Fischer
/ December 18, 2015Richard,
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
Richard M. Hicks
/ December 23, 2015Hi 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! 🙂
Pm
/ May 19, 2017Hello Richard,
Thank you for your valuable blog.
We are currently evaluating DA F5 pre auth for IP HTTPS.
Everything is working as expected but we found out that if the client has multiple certificates in its store with private key then he presents the wrong certificate to our ADC.
The client authentication is then rejected since cert is not trusted.
We did not find a way to bind DA IP https to the right machine certificate.
Is that possible?
Thanks a lot.
Richard M. Hicks
/ May 19, 2017That’s not a scenario I’ve encountered before. Are all of the certs issued by your internal PKI? If so, I would think it would still work. I’m not aware of a way to configure the F5 to ask for a specific certificate, unfortunately.
Pm
/ May 19, 2017The issue we faced was with a self signed cert in the computer certificate store. I removed it and ip https connection was successful again. I could even reproduce by adding a self signed cert on a random computer. I am not aware of a way to ask the client for a specific cert on f5 either but I guess we should be able to bind the right cert on the DA client. Anyway thanks a lot for your answer.
Richard M. Hicks
/ May 20, 2017Thanks for the update. I’m always interested in hearing what other’s experience is like. Thanks for sharing! 🙂
Martin
/ February 15, 2018Hello,
we’re currently in the process of deploying DirectAccess for our organization and we’re experiencing problems with failover.
DirectAccess is loadbalanced using F5 Big-IP.
The problem is that if I shutdown one DirectAccess server, the clients are able to move to available node the first time, but for the next failover they are unable to reconnect to available node.
They are completely stuck connecting until we reset VIP in Big-IP. When the clients are stuck they successfully perform the SSL handshake and deliver payload to server, but then they get a reject packet in return.
F5 has told us that “unexpected ssl failovers” just aren’t supported because they leave stale connections.
Do you have any experience with this kind of issue?
Martin
Richard M. Hicks
/ February 15, 2018That’s not something I’ve ever encountered myself. I do know that many load balancers require additional configuration to actively terminate connections when the real server/pool member goes offline. I’m not aware of any issues with failover/failback though. I’ve used the F5 quite often over the years and never had any issues like that.
JP
/ August 22, 2018We have configured it as explained above but we are getting the following error: Unable to get local issues certificate (48) we have two Certificate Authority Servers and the are added under Advertised Certificate Authorities with the CA root cert in Trusted Certificate Authorities. Any ideas?
Richard M. Hicks
/ August 25, 2018It might be that the client is presenting the wrong certificate when prompted by the F5. Unfortunately there’s no good way to perform certificate selection on the client in this scenario. If you have multiple certificates that might work (those with client authentication EKU) this might not work. There’s nothing you can really do on the load balancer side either (for example using iRules) because it is the client that chooses which certificate to present when challenged.