ISATAP Recommendations for DirectAccess Deployments

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 translatorsDNS64 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!

Leave a comment

46 Comments

  1. ipxfer

     /  July 11, 2013

    Thanks for the great article. I have an ISATAP setup through the GPO for specific management client in order to manage out. It worked like a charm until I introduced NLB for DA. Do you have any thoughts how I can do both NLB and managed out without deploying ISATAP globally? Thanks.

    Reply
  2. Casey Brennan

     /  August 1, 2013

    It appears that the Troubleshooting Portal URL was removed from the DCA 2.0 group policies — can you confirm that? Was nice to have that.

    Reply
    • Confirmed. It was removed because the DCA 2.0 was designed for Windows 7 clients connecting to a Windows Server 2012 DirectAccess server, which obviously doesn’t include a web portal as the Forefront UAG 2010 product does.

      Reply
      • Casey Brennan

         /  August 6, 2013

        Thank you. I initially didn’t make that connection — I thought it was just a Help Portal page of your own choosing that you could point users to. In my opinion it was useful to have, but I can see that it’s now gone……thanks again.

  3. Cory

     /  September 9, 2013

    Thanks for the great aticle, I did read Jasons artilce aswell; however, I still have a quick question.

    When you refer to manged out servers are you refering to AV, SCCM, Backup services only? In other words which servers should be in the GPO? Are DNS/ADUC servers required to be in the ISATAP GPO, I owuld think they proivde DNS services to the DA clients.

    Thanks

    Reply
    • Any server that you want to initiate outbound communicate to DirectAccess clients from should be included in the ISATAP GPO. They key here is “initiate”. AD/DNS/SCCM don’t typically need to be ISATAP enabled because the clients initiating the connections.

      Reply
  4. Cory

     /  September 10, 2013

    Richard,

    Thanks this does clarify things a little.

    So if I don’t have any “managed out” servers then do I need ISATAP at all?

    Reply
    • That’s correct. Unless you have a specific need to *initiate* outbound communication to at DirectAccess client there’s no need for ISATAP.

      Reply
  5. itismeap

     /  March 11, 2014

    If you have ISATAP router/server running on a Windows 2012 Box (also running DA), is there a way to see all the ISATAP hosts currently connected it? After some research it seems that we might not need ISATAP on our network (we don’t need manage out capabilities) and that NAT64/DNS64 will take care of getting access to the internal IPv4 resources. We’d like to turn it off however before doing that I’d like to see which hosts are connnected and if necessary put them in a GPO for ISATAP access.

    Thanks

    Reply
  6. Andrew

     /  April 24, 2014

    Perhaps I am misunderstanding things, but how does one specify/add a list of networks to be routed over the DirectAccess tunnels? (“interesting traffic” in Cisco speak). for e.g. if I have some hosts on a different subnet at my HQ (where the DA server is running), I need to tell my DA client, you can get to that subnet via the DA server. I see DA adding routing entries on the DA client for the DA server’s “inside” interface subnet (where the DC and DNS are located) but what about other resources located on non-local subnets?

    Reply
    • With DirectAccess, you don’t specify “interesting traffic” via IP networks. Rather, it is handled by the namespace itself. Interesting traffic would be considered anything in the corp.example.net namespace, for example. You don’t specifically tell the client how to get to internal subnets via the routing table. That is handled by the DirectAccess server. The DirectAccess server itself should have network connectivity to all internal subnets that need to be reached by DirectAccess clients. If you’ve configured your DirectAccess server dual-homed, the internal network interface will require static routes to any remote internal subnets, of course. More details here: https://directaccess.richardhicks.com/2013/06/19/network-interface-configuration-for-multihomed-windows-server-2012-directaccess-servers/

      Reply
  7. itismeap

     /  April 25, 2014

    @Andrew if I understand your question, I think you need to add the hostname to the NRPT table eg http://technet.microsoft.com/en-us/magazine/ff394369.aspx

    Reply
  8. Andrew

     /  April 26, 2014

    Thanks for the explanation Richard.

    So if I understand correctly, reachability from the client to remote hosts over DA is very much dependent on DNS. If for e.g. I had a remote subnet at the HQ (that the DA server can get to via a static route), trying to reach that host via its IPv6 address only will fail?

    I will need to refer to that remote host by it’s FQDN, for which the HQ DNS server will return a AAAA record and somehow the client will know to route that traffic over the tunnel.

    PS: I followed your multi-homed server guide when deploying DA, thanks for that – great article!.

    Reply
    • Largely dependent on DNS, yes, but not entirely. You can connect via IPv6 directly in some cases. For example, if you have IPv6 running on the internal network you can connect directly via IPv6 address. If the internal resource is IPv4, you can connect directly to the NAT64 IPv6 address. A NAT64 address is returned by the DNS64 service for hostname look ups, but you can always derive the NAT64 address by using the IP-HTTPS prefix and appending the IPv4 address in HEX. For example, if I want to connect to IPv4 address 172.16.1.225 and my IP-HTTPS prefix is fd03:b402:e10c:7777::/96, the NAT64 address would be fd03:b402:e10c:7777::ac10:1e1. This is helpful in situations where you might want to SSH in to a router from a DirectAccess client and the router doesn’t have a hostname registered in DNS.

      Reply
  9. Frédéric Barbier

     /  October 8, 2014

    It seem that ISATAP isn’t supported in DirectAccess 2012 deployments, so you need implement native IPv6… http://technet.microsoft.com/en-us/library/dn464274.aspx

    Reply
    • Not officially supported, no. However, the DirectAccess server is still configured as an ISATAP router by default, so it can still be used in some instances.

      Reply
  10. Michael Wieland

     /  October 31, 2014

    Hi Richard, thx for your blog it really helps a lot. Anyway I can´t get managed out working in our environment. I setup the DNS records for the 2 DA servers and the load balancer address. I implemented the GPO and the router name is ping able without any issues. But I do not get any iIPV6 address on the machine which is setup to be able to do the managed out. Just get a linked local. The firewall between the “management server” and the DA is set to allow any traffic between those machines. But the only thing I get is the link local ipv6 address. I have seen a firewall rule on the DA server itself which is saying “Block Inbound RS to ISATAP DIP” is that the way it should be or is that one blocking my ISATAP requests from the management machine?

    Reply
    • Does the DirectAccess server have a global address on it’s ISATAP interface?

      Reply
      • Michael

         /  November 4, 2014

        What do you mean with global address? Internet address? Ist a one NIC Installation. So the DA Servers do have a IP4 address from the DMZ.

      • The ISATAP tunnel adapter should have two IPv6 associated with it. One should be link local (begins with fe80) and the other should be global (begins with 2002 or fd).

      • Michael

         /  November 9, 2014

        Hi Richard, yes I know, but I don´t get the 2. one. Is there a procedure how it can be triggered to request one. Or actually a log where I could see the reason why it did not get that global one. I just get the linked local and the other one I´m missing :-(.

      • Try running the following command on your DirectAccess server:

        netsh interface ipv6 set interface forwarding=enabled advertise=enabled

        …where is the interface name or index number of the DirectAccess server’s internal network interface. Restart the IP Helper service on both the DirectAccess server and client and let me know what happens.

  11. Darren

     /  February 2, 2015

    I too am having the same issue as Michael, however my DA setup is slightly different. I have 2 DA servers which are setup separately and located in different offices. One is a live test environment which also acts as a standby should the main DA server suffer a problem.

    After using DA for several months I would like to finish off the project and get ManageOut working. I have followed guides by yourself and others regarding setting up a selective ISATAP environment with no success.

    My DA server is running Windows Server 2012 R2, with dual NIC and 2 consecutive external IP addresses. Teredo works correctly and clients have full network connectivity. I have created an A record pointing to the Internal IP address. I have created new group policies which only applies to members of a specific AD group. My test machine which is a member of that group gets the correct group policy options and can ping the DNS name successfully.

    However, when I run an ipconfig /all command, the machine only has an FE80 link local address against the isatap adapter. When I run ipconfig /all on the DA server I see multiple ISATAP entries for both 2002 and FE80 addresses.

    Any ideas as to what I can try next?

    Reply
    • On the DirectAccess server, try issuing the following commands from an elevated command prompt:

      netsh interface ipv6 set interface forwarding=enabled
      netsh interface ipv6 set interface advertise=enabled

      Here, is the interface index of the ISATAP tunnel adapter on the Internal network. It should be the interface with the 2002 IPv6 address assigned to it.

      Let me know if that works for you!

      Reply
      • Hi Richard, I tried those commands earlier after you suggested it to a previous poster and my test machine successfully received an IPV6 (2002) address on its ISATAP adapter 🙂

        However, further investigations would indicate that DA clients are NOT registering the IP addresses in DNS. On a DA connected laptop I obtained its IPHTTP address via ipconfig and successfully ping’d and RDP’d onto it via my test machine. However, I could not ping its Teredo address. When I look at DNS, the DC only has the internal IPv4 address.

        Any ideas as to what might be the cause of this behaviour? So far everything I have read on previous forums does not help. Our internal DNS is AD integrated and set to Secure Only.

      • You may need to make changes to DirectAccess client Windows firewall policies to allow ICMP to the Teredo address. Specifically, the firewall rule allowing ICMP should be configured to “allow edge traversal”. Regarding the registration of IP addresses in DNS, that could be caused by any number of things. In my experience the registration doesn’t occur immediately, so you may have to wait for a period of time.

  12. Hi Richard, I am trying to get ManageOut working on my live DA server and still cannot get a helpdesk machine to receive a 2002 address on the ISATAP adapter.

    The DA server has 2 NIC’s (Internal and External), ipconfig shows the Ethernet adapter Internal: has an ipv6 address starting 2002.However, I also have the following entries:

    Tunnel adapter isatap.{398A04ED:xxxxxx:A4C2-B653EAFB34A9} Only has an FE80 address
    Tunnel adapter isatap.{398A04ED:xxxxxx:BA4C2-B653EAFB34A9} 2002 and FE80 but the IP address bound to the Internal NIC but for the SSTP RAS service.
    Tunnel adapter isatap.{5903AA55:xxxxxx:BE10-454499D3FF91}: fe80 and the link local ip contains the static internal ipv4 address assigned to the Internal NIC.

    When I run netsh int ipv6 show route to get the Index number I am unsure which one I should run the following commands on:
    netsh interface ipv6 set interface forwarding=enabled
    netsh interface ipv6 set interface advertise=enabled

    I have checked the current status using netsh int ipv6 show int INDEXNUMBER and what I think is the Internal ISATAP adapter returns

    Forwarding : enabled
    Advertising : enabled

    Do you have any other ideas as to what might be causing the problem?

    Reply
    • You’d run the commands for the interface index corresponding to the internal network interface. Typically enabling forwarding and advertising on that interface resolves the issue. However, if your ISATAP client is unable to resolve the correct IPv4 address of the DirectAccess server, or perhaps the firewall isn’t allowing the traffic, those could also be possible causes.

      Reply
      • Many thanks for your help so far Richard. Within device manager I uninstalled all the ISATAP adapters and then added a dns suffix to the internal NIC (ipv4). I rebooted the server and then ran the following commands on the newly created ISATAP adapter on the Internal NIC.

        netsh interface ipv6 set interface forwarding=enabled
        netsh interface ipv6 set interface advertise=enabled

        It worked, my test helpdesk machine now receives a 2002 address 🙂 I can ping and RDP onto a DA client. However, DA clients are not publishing their ipv6 address to DNS so I am unable to connect via hostname only.

        Should DA clients publish their iphttp (2002) and or teredo (2001) addresses to DNS.

      • Good to hear! Yes, your DA clients should automatically update their records in DNS to reflect their new IPv6 address. If that’s not happening, I’d investigate why dynamic updates aren’t working (I’m assuming you have dynamic updates enabled, of course!).

  13. Larson

     /  August 4, 2015

    We have dual-NIC DA servers load balanced behind an edge device. I am confused as to what is supported for 2012. If my edge device only supports IPv4 am I able to use ISATAP with my configuration or not because they are load balanced?

    Reply
    • ISATAP is supported for DirectAccess in small and mid-sized deployments with a single DirectAccess server, or an array of DirectAccess servers configured to use Windows network load balancing (NLB). ISATAP is not supported when external load balancers are used, or for multisite deployments. However, it is possible to configure ISATAP with external load balancers and multisite using an external ISATAP server. I’ve done this numerous times and it works perfectly. 🙂

      Reply
  14. John

     /  December 9, 2015

    It would be great to see a blog post on configuring ISATAP using an external ISATAP server. Are you doing this with WIndows Server?

    Reply
    • Yes, just a Windows Server 2012 R2 box works for this. It’s a pretty complex configuration. I hope to document it sometime in the future though. 🙂

      Reply
  15. Gus

     /  March 10, 2016

    I’ve set this up, but for some reason, I’m not getting a default gateway on my ISATAP adapter.

    I have two DA servers configured using a hardware load balancer. I have three DNS entries (one for each actual IP and one for the VIP).

    Any ideas on why the default gateway isn’t appearing?

    Reply
    • ISATAP is not supported and does not work when DirectAccess is configured to use an external load balancer. It is possible using a custom configuration to get manage-out using ISATAP to work in this scenario, however. If you’d like more information about this, contact me directly.

      Reply
      • Adam

         /  April 6, 2016

        Hi Richards,
        Thanks for the valubale post and the reply to the questions. I have similare setup to Gus and it will be great if you can email me the info about this senario or setting up ISATAP an external ISATAP server.
        Thanks,
        Adam

      • Drop me a note and I’ll explain more then. 🙂

      • Julie Basler

         /  February 23, 2017

        Asking about your comment:” ISATAP is not supported and does not work when DirectAccess is configured to use an external load balancer. It is possible using a custom configuration to get manage-out using ISATAP to work in this scenario, however. If you’d like more information about this, contact me directly.”

        We are currently trying to set up manage out using a similar configuration.
        We have 2 DA servers and an external load balancer on the same subnet.
        I’ve added the physical IPv4 IP’s from the 2 DA servers, the virtual IPv4 IP of the DA farm and the physical IPv4 IP from the external load balancer into our Fox_Isatap dns entry.
        Group policy is configured per the Jordan Krause blog which is identical to Jason Jones’ article:
        https://www.packtpub.com/books/content/configuring-manage-out-directaccess-clients

        After rebooting our client sets to pull the group policy settings we are still not able to even ping our Direct access clients.

        any help would be appreciated

      • Implementing ISATAP in this scenario requires the implementation of a separate ISATAP routing infrastructure. Reach out to me directly and I’ll provide you with additional details.

  16. Jason

     /  April 13, 2016

    I’m curious about properly removing ISATAP once it has been in place (for several years). We originally had UAG then later on migrate over to Direct Access on 2012 R2. I had read that the best practice for DA was to stop using/remove ISATAP in large environments. Back with UAG it was best practice to enable it globally via DNS. So I removed all the ISATAP DNS entries … a couple of years ago now….but I still see plenty of IPV6 quad a records in DNS and I have DA users running into issues “from time to time” connecting to services where it’s trying to make an ISATAP connection and to resolved the issue I simply disable IPV6 on the downstream system and it stops advertising IPV6. So I’m left with thinking that I still need to do something in the 2012 DA environment to disable ISATAP on the interfaces perhaps. I just want to “safely” remove it without causing any downtime or issues for the clients that connect to DA. 🙂

    Reply
  17. Bryan

     /  December 20, 2016

    My DirectAccess Deployment is working well so far. Single-server, 2012 R2, and remote clients are able to reach internal network resources. I’ve now followed the steps in the excellent Jason Jones blog post and once I’m back in the office, will test Manage Out to see how it works.

    “What’s that?” you say. “Back in the office?” Yes, I’m not just the administrator of DirectAccess, I’m also a client! It makes some things easier for me, which leads me to wonder – when *I* am offsite and am operating as a DA client, will ISATAP routing work for me to manage out to other offsite DA clients? I’m inclined to think this is an edge case, but I don’t know enough about the how the IPV6 transition technologies work together on the DA server to know what to expect.

    Thanks for a great blog!

    Bryan

    Reply
  1. DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 | Richard Hicks' DirectAccess Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: