Design considerations for implementing Direct Access in Windows Server 2012

We recently upgraded our Direct Access solution to Windows Server 2012, and during this process we came upon several design considerations coming into play, which I thought I’d share with you. The getting started wizard gives you the option of setting up DirectAccess without PKI. Great, right?

Well, maybe, depending on your preferences. You lose out on force tunneling, Network Access Protection (NAP) integration, and the two-factor authentication. Since we use smart cards for login and bitlocker-to-go, this was not an option. And many companies might see the ability to force client Internet traffic through company proxys as a very attractive option. My recommendation would definitely be to set up a stabile PKI environment – you are going to need it anyway in so many other technical implementations.

You have the option to implement NAT64 and DNS64, basically eliminating the need for internal IPv6 transition technologies or internal native IPv6 adressing. Now using ISATAP internally in windows 2008 R2 was …error prone to say the least. And to make the transition to IPv6 is a daunting task. Prior to Windows Server 2012, the solution was to implement the UAG, but now we have the option built into Windows Server 2012. But two things should still be taken into consideration.

  •     You still have to test your client-side installed applications, because they will still be using IPv6.
  •     Your internal IPv4-only machines will be unable to initiate connections to DirectAccess clients for remote management, since the adress     translation is unidirectional from the DirectAccess clients. Due to the Isatap-problems in 2008R2, we had already implemented IPv6 internally, meaning we had little use for this feature.

Edge or NAT? In Windows Server 2008 R2 you had to set up Direct Access with two consecutive public IP adresses, the reason being that this was required to set up a functional Teredo server (IPv6 transition technology for DA clients behind a NAT-device). Now you have the choice to place the DA server behind a NAT device, and not use two public adresses. In this configuration, only IP-HTTPS is used. In my opinion, this is a great change. I have seen several customers having problems with their Direct Access implementation due to the fact that the mobile phone network they were using had a public adress space that was adress-translated by the operator. This had effects like both 6to4 and Teredo being initiated by the DA client leading to connection failures. For these customers, we had to disable Teredo. Now, this used to come at a performance degradation since the DA client had to use IP-HTTPS with the overhead of double encryption as soon as it was behind a NAT-device, but improvements to the IP-HTTPS protocol in Windows 2012 have increased its efficiency. Due to this, I would definitely not hesitate to use the NAT option for DA server implementation.

Finally, there is a new feature called “Manage-out only”. Personally, I can’t help but feel that it seems like a waste of effort to implement a technology such as Direct Access and not use it for…well access. But fine, if all you wish to achieve is a manage out solution, you can set it here.

Many new other changes have been implemented in Direct Access in Windows Server 2012, but the above are the ones directly affecting your design.

Best regards,

Mårten Thomasson
Senior Consultant

Posted in Blog, Windows Server 2012 R2.