Enable Manage Out in DirectAccess

What is DirectAccess Manage Out and what’s all the fuzz about? Well to begin with, Manage Out is the concept of managing remote DirectAccess connected computers from an internal computer. When implementing DirectAccess for the first time it’s easy to believe that if remote computers can connect to inside computers/servers then inside computers/servers must be able to reach DirectAccess connected clients right? Nope, it’s not that easy unfortunately. Why is that? It’s because of the mechanism that makes the magic behind DirectAccess work and its limitations. As I guess you know, DirectAccess is a strict IPv6 technology and since almost none of us has implemented IPv6 in our corporate networks yet, we need some sort of magic glue between IPv6 and IPv4. Enter IPv6 protocol translation. Two of those protocols that are making DirectAccess IPv6 clients able to talk to internal IPv4-only resources are NAT64 (RfC:6146) & DNS64 (RfC:6147). Before I bore you to death, my point is that these translators only work one-way; from IPv6 to IPv4, not the other way around, which is what we try to do when connecting from an internal IPv4 computer to our IPv6 connected DirectAccess computers. We need more magic glue. Enter ISATAP (RfC:5214)!

Okay, so now we know what we want and why we need it, but how to implement it then? There are some things to consider when thinking about making use of ISATAP. First of all is that it’s not really made for production networks. At least not large networks, according to this article https://technet.microsoft.com/en-us/library/dn464274.aspx#bkmk_isa by Microsoft. In it, Microsoft says “If ISATAP is deployed in a multisite, load balancing, or multidomain environment, you must remove it or move it to a native IPv6 deployment before you configure DirectAccess.“ For most of us, that’s a pretty tall order. If you’ve never dealt with IPv6 before just looking at the IPv6 addresses is scary enough. But keep calm. We have options. Option 1 is to manually set an IPv6 address on one or more management computers (instead of the whole network) and go native IPv6 in a minimized fashion. The process of how to go about that route is described in this article http://blogs.technet.com/b/jasonjones/archive/2013/04/02/windows-server-2012-directaccess-manage-out-using-native-ipv6.aspx by the brilliant Jason Jones. It’s possible I guess but my fear of taking that specific path is the question if your network is capable of routing IPv6 packets. Is it? I don´t know?!

So I’m going with Option 2 which is implementing a mini ISATAP network on top of the regular old IPv4 network. Once again Jason Jones comes to the rescue; http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html It’s written with Microsoft UAG in mind but the DirectAccess in UAG is more or less the same as in Windows Server 2012/R2 so it’s applicable. One final pre-reading tip is Deb Shinders excellent article about how ISATAP work; http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Configuring-ISATAP-Router-Windows-Server-2008-R2-Part2.html In the early days of DirectAccess, Server 2008 R2 that is, there was no built-in ISATAP Router like there is now, so we don’t have to care about building one, but its inner workings are the same.

And now, finally to my reason for blogging about this 😉 When I tried this in my home lab environment (and I’ve seen this in customer production implementation as well) it doesn’t work? Why can’t I connect to the DirectAccess connected clients? What’s wrong? If you did your homework and read Deb’s article you know that the ISATAP Router has to advertise itself and also forward IPv6 packets. You enable these functions on the ISATAP Interface on the ISATAP Router. Since my DirectAccess implementation is a 2-node WNLB cluster with 2 NICs in each server I get 4 ISATAP adapters created in Windows. You can see them by using netsh interface ipv6 show interface:

As you can see it’s not clear which one is bound to the external NIC and which one is bound to the internal NIC. Remember that ISATAP is a feature for internal IPv4 clients to be able to reach external IPv6 hosts, so the advertisement and forwarding is needed on the internal ISATAP interface. There is a way to find out by using wmic <ENTER> nicConfig get Description,SettingID The column SettingID is the GUID of the physical NIC and that is also what is shown after isatap.{guid}. After digging around in my DirectAccess server I could see that forwarding and advertising was enabled on the external NIC instead of the internal which of course isn’t going to work. We need to fix this. A quick way would be just to enable the needed features on the ISATAP adapter for the internal NIC but there is a way to make this more crisp and clear.

Simply:

Go into Device Manager
Under View, click Show hidden devices.
Uninstall both ISATAP adapters
On the Internal NIC, IPv4 Settings, Advanced, DNS tab, fill in your internal domain’s DNS suffix
Reboot the DirectAccess server
Proceed with Node 2, etc if you have multiple DirectAccess servers.
After reboot it’s clear what adapter is the internal one
Now we only have to enable Forwarding and Advertising; netsh interface ipv6 set interface 32 advertise=enabled forwarding=enabled