DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

Windows Server 2012 DirectAccess Video Training Course Now Available

I’m pleased to announce that my Windows Server 2012 DirectAccess video training course is now available from TrainSignal! The course covers planning, installing, and configuring DirectAccess in Windows Server 2012 in a variety of different deployment scenarios. Here’s the course outline:

Lesson 1 – Introduction
Lesson 2 – DirectAccess Overview
Lesson 3 – Planning for DirectAccess
Lesson 4 – Configuring DirectAccess (Simplified Deployment)
Lesson 5 – Configuring DirectAccess (Complex Deployment)
Lesson 6 – Configuring DirectAccess (Multi-site Deployment)
Lesson 7 – Enabling Support for Windows 7 DirectAccess Clients
Lesson 8 – Enabling High Availability with Network Load Balancing
Lesson 9 – DirectAccess Monitoring and Reporting
Lesson 10 – DirectAccess Troubleshooting
Lesson 11 – Enabling Legacy Remote Access VPN

Special thanks goes to my friend and fellow MVP Jordan Krause who served as the technical reviewer for this series and provided valuable input and feedback during the production of the course. Before you implement DirectAccess with Windows Server 2012, be sure to sign up for a subscription at and not only will you receive this great DirectAccess training course, you’ll have access to the entire TrainSignal library of content for just $49.00 per month!

TrainSignal Windows Server 2012 DirectAcess Video Training Course

DirectAccess Clients and TPM

I’ve been frustrated recently with a number of articles and blog posts I’ve seen indicating Windows 8 DirectAccess clients connecting to a Windows Server 2012 DirectAccess server require a Trusted Platform Module (TPM) and the use of smart cards for authentication. This is a myth, and nothing could be further from the truth. TPM and smart cards are indeed supported (TPM with Windows 8, smart cards with Windows 7 and Windows 8 DirectAccess clients) but they are not explicitly required. For the posts I’ve seen I have asked the authors to correct their statements, and to their credit some of them have. Others, unfortunately, have not. I’m not sure if they are simply misinformed or if they are deliberately misleading their readers to downplay DirectAccess in an effort to sell another VPN solution. Regardless, I am compelled to set the record straight here. So, to be perfectly clear:

TPM is NOT a requirement for DirectAccess clients.

There you have it. Now go out and deploy DirectAccess today!

Features Deprecated in Forefront UAG Service Pack 3

With the recent release of Service Pack 3 (SP3) for Microsoft Forefront Unified Access Gateway (UAG) 2010, Microsoft has published a list of features in UAG SP3 that have been deprecated. To be clear, this does not mean these features cease to function after you install SP3 on UAG! It is simply meant to give network engineers and security administrators an idea about what features are likely to be removed from future releases of Forefront UAG. Some of the deprecated features should come as no surprise. For example, DirectAccess support in Forefront UAG is now deprecated in favor of DirectAccess in Windows Server 2012. Also, features such as Secure Sockets Tunneling Protocol (SSTP) for client-based remote access are better handled using the remote access role in Windows Server 2012. Other deprecated features may present more of a challenge if you’ve been relying on them to provide secure remote access to applications, such as the deprecation of support for some authentication repositories (e.g. Novell Directory, Notes Directory, TACACS) or the Java-based Session Cleanup tool. For a complete list of deprecated features in Forefront UAG SP3, click here.

Hotfix for Windows 7 DirectAccess Clients

This month Microsoft released an important hotfix to address a DirectAccess connectivity issue for Windows 7 clients connecting to a Windows Server 2012 DirectAccess Server. The hotfix specifically resolves an issue where Windows 7 clients face a very long delay reestablishing a DirectAccess session using the IP-HTTPS IPv6 transition protocol after recently disconnecting from a VPN session. In this scenario, Windows 7 DirectAccess clients may take as long as 15 minutes to automatically reestablish a DirectAccess session using IP-HTTPS. During this time the IP-HTTPS adapter state is displayed as disconnected. Refer to Microsoft KB 2796313 more information and to download the hotfix.

Windows Server 2012 DirectAccess IP-HTTPS and Windows 7 Clients

With Windows Server 2008 R2, IP-HTTPS used standard SSL cipher suites to encrypt sessions. However, those sessions are already encrypted using IPsec, which is needlessly redundant. The protocol overhead for this double encryption placed an extreme burden on the DirectAccess server in terms of CPU utilization and memory consumption. Throughput and performance suffered greatly in large deployments. To address this issue, Microsoft included two new SSL cipher suites in Windows Server 2012 and Windows 8 that use NULL encryption. IP-HTTPS sessions are fully authenticated, but encrypted only once using IPsec. This significantly reduced resource demand on the DirectAccess gateway and improves performance greatly. Unfortunately, only Windows 8 clients can take advantage of this new IP-HTTPS functionality in Windows Server 2012 DirectAccess. When Windows 7 clients establish an IP-HTTPS session with a Windows Server 2012 DirectAccess gateway they will still request the use of fully encrypted cipher suites, as shown here:

Windows 7 IP-HTTPS Client Hello

Windows 7 DirectAccess IPHTTPS Cipher Suites

Windows 8 IP-HTTPS Client Hello

Windows 8 DirectAccess IPHTTPS Cipher Suites

Windows 8.1 IP-HTTPS Client Hello

Windows 8.1 DirectAccess SSL Cipher Suites

So, if you want to take advantage of the IP-HTTPS performance improvements in Windows Server 2012 DirectAccess, be sure to use Windows 8 clients!

Update: Recently with the help of the folks at F5, I developed a solution to emulate Windows 8 client behavior for Windows 7 DirectAccess clients using the F5 BIG-IP Local Traffic Manager (LTM). Using this technique allows you to *effectively* offload SSL for Windows 7 DirectAccess clients. Fore more details click here.

Presenting DirectAccess at Microsoft TechDays Belgium 2013

Join me in Belgium for Microsoft TechDays 2013! The event takes place at Kinepolis in Antwerp on March 5-6-7. I will be presenting a session on DirectAccess in Windows Server 2012 on March 7. The event will include sessions from many top speakers including Marcus Murray, Paula Januskiewicz, Tom Decaluwe, and more. There will be separate tracks for IT professionals and developers, so there will be something of interest to everyone. In addition, all attendees will receive a free 3 month TechNet subscription. Register today and don’t miss out on this amazing event!

Microsoft TechDays Belgium 2013

DirectAccess and the Microsoft Surface Pro

With the recent release of the Microsoft Surface Pro, many people have been asking me about DirectAccess connectivity for these devices. One of the requirements for DirectAccess connectivity is that the device be joined to a domain, a capability that the Surface RT lacked. Although the Surface Pro runs the full version of Windows 8, it is Windows 8 Professional. Sadly, DirectAccess connectivity is only supported for Windows 8 Enterprise edition clients, along with Windows 7 Enterprise and Ultimate editions.

Windows Server 2012 DirectAccess Client Requirements

So, if you have just purchased a new Microsoft Surface Pro and are hoping to configure it as a DirectAccess client, I’m afraid you’re out of luck. In my opinion, the lack of DirectAccess support for Windows 8 and Windows 7 Professional is a serious flaw, especially when you consider all of the great use cases you can imagine when you have a full featured tablet with always-on, secure remote network connectivity. It’s a shame, really. Let’s hope this changes in the future!

Update: Read my post on how to install Windows 8 Enterprise and configure DirectAccess on the Microsoft Surface Pro here.

December 2012 Windows Updates and DirectAccess Connectivity Issues

The December 2012 collection of Windows updates included a number of changes that may adversely affect connectivity for DirectAccess clients. The December updates included changes to the Windows Root Certificate store and a hotfix for the IP Helper Service. Either or both of these updates could potentially prevent DirectAccess clients from connecting via the IPHTTPS IPv6 transition protocol. For more information read this post from the Forefront UAG Product Team.

Discussing DirectAccess on the People Talking Tech Podcast

Recently I had the opportunity to chat with fellow Microsoft Most Valuable Professional (MVP) Denny Cherry on his People Talking Tech podcast. We had a great time conversing about DirectAccess in Windows Server 2012. Give it a listen!

%d bloggers like this: