From a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the Intranet, Windows Server 2012 DirectAccess (as well as Forefront UAG/DirectAccess) includes two important protocol translators – DNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients. To support outbound communication originating from the Intranet to connect DirectAccess clients, the DirectAccess server is configured as an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router. ISATAP is an IPv6 transition protocol that allows hosts on the intranet to initiate outbound communication to DirectAccess clients on the Internet by tunneling IPv6 communication over the internal IPv4 network. ISTAP is enabled by populating internal DNS with a host record called ISATAP that resolves to the IPv4 address assigned to the Internal network adapter on the ISATAP router, in this case the DirectAccess server (don’t forget to remove ISATAP from the DNS global query block list!). When a client resolves ISATAP to an IP address successfully, it enables an ISATAP tunnel adapter and assigns itself an ISATAP IPv6 address. Once enabled, any host with an ISATAP tunnel adapter configured can initiate outbound communication to DirectAccess clients on the Internet.
When configured and enabled, ISATAP opens up new and interesting network communication scenarios. For example, a helpdesk engineer can proactively initiate a remote desktop session to a remote client connected via DirectAccess to troubleshoot an application. Systems management engineers can push software out to DirectAccess clients without requiring an agent on the remote client to “phone home” to receive software updates. This model is often referred to as “manage out”.
In the early days of DirectAccess with Windows Server 2008 R2 and Forefront UAG, configuring and enabling ISTAP as described above was standard operating procedure. However, we soon learned that there are some serious drawbacks to deploying ISATAP. While the DirectAccess manage out scenario is an important and frequently requested feature of a DirectAccess implementation, it often causes more trouble than it solves. In its default configuration, ISATAP is a global change that affects all hosts that can resolve the hostname ISATAP to an IP address. The challenge here is that this change can break or impair normal network communication for some hosts on the Intranet. For example, if an Intranet host is able to resolve a public hostname to an IPv6 address, it may attempt to connect to the site via ISATAP. Unfortunately, in this scenario ISATAP does not lead to the public Internet. Rather, ISATAP is used to provide network connectivity exclusively for our DirectAccess clients. Since IPv6 is preferred in most modern operating system’s networking stacks, it can lead to failed or seriously delayed communication to Internet resources. In addition, once ISATAP is enabled globally there will be a lot of IPv6 communication taking place on the network, which in large enterprise networks can be a source of confusion for those individuals with the responsibility for monitoring the network.
ISATAP also suffers from a lack of robust monitoring tools for this very essential service. Additionally, ISTAP turns the OSI model upside down. ISATAP relies on upper-layer protocols (DNS) to provide its service. If there are issues with DNS that prevent proper name resolution, ISTAP routing will cease to function, which is fundamentally backward.
As I mentioned earlier, by default, ISATAP is a global setting. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the Intranet to DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you deploy IPv6 on any internal systems that will participate in any DirectAccess manage out scenarios. Unfortunately this will not be possible in many cases, as additional network changes are often required to support IPv6 on the Intranet. In these cases we recommend that instead of configuring ISATAP in DNS globally, you target individual systems for ISATAP configuration as required. This can be accomplished in a number of ways.
Group Policy – This is best way to deploy ISATAP settings to systems that require DirectAccess manage out functionality. It is the easiest to manage and the most scalable as well. It involves creating a unique ISATAP hostname and assigning it to individual systems via group policy. Thankfully my buddy Jason Jones has already documented that process here, saving me the time and effort of doing it myself. Why reinvent the wheel, right? : )
PowerShell – Using PowerShell is an alternative method of configuring an individual system to use ISATAP. Although not as scalable as the group policy method, it is still very effective. On the system that requires network connectivity to DirectAccess clients, from an elevated PowerShell prompt execute the following command:
Set-NetISATAPConfiguration -Router <NameOrIPAddress>
Netsh – Another command line method for configuring the ISATAP is to use netsh.exe. From an elevated command prompt execute the following command:
netsh interface isatap set router <NameOrIPAddress>
HOSTS file – This is the least desirable way to configure ISATAP, but I’ll mention it here because it is quick and simple and does work. On any system that requires ISATAP for DirectAccess manage out, simply edit the HOSTS file in C:\Windows\System32\Drivers\Etc and add a host record for ISTAP that resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. Obviously this is the least scalable alternative and should only be used in test environments or very small production networks.
As you can see there are numerous drawbacks to configuring ISATAP on a global scale. Fortunately there are simple and effective workarounds that allow you to target specific systems for ISTAP configuration. Choose the one that works best for you and have fun managing your DirectAccess clients!