Limiting ISATAP Services to DirectAccess Manage Out Clients


Please Note: This blog post was adapted from a previous UAG DirectAccess blog post and was originally written when the use of ISATAP for the Manage Out scenario was fully supported by Microsoft. However, with the advent of Windows Server 2012 supportability for the use of ISATAP was specifically limited to a single server topology due to known scaling and reliability issues as summarised in the following TechNet reference: https://technet.microsoft.com/en-us/library/dn464274.aspx#bkmk_isa

A common requirement, or ask, for many DirectAccess deployments is the need to remotely manage DirectAccess clients when they are away from the corporate network. This functionality is often termed ‘manage out’ and is one of the major benefits of a DirectAccess solution when compared to traditional VPN remote access solutions. The ability to reach a managed client, irrespective of their location, irrespective of whether they are logged in, is a power tool for IT administrators.

However, the need for corporate connected manage out clients to be IPv6 capable often presents a challenge when not running IPv6 within the intranet environment. This challenge is often met by configuring an intranet IPv6 transition technology called Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP for short.

Unfortunately, the ISATAP mechanism uses a hard coded DNS lookup process that is automatically enabled on on Windows Vista and above operating systems. This DNS lookup requires the creation of a global ‘isatap.domain.com’ DNS host record, and this will ultimately enable ISATAP by way of an ISATAP router,. The router will automatically assign IPv6 addressing and prefix information, across the entire Windows Vista+ environment. In some scenarios, enabling IPv6 support globally using ISATAP is desirable, but for many deployments, adding IPv6 capabilities to all Windows systems is not desirable; especially when Windows will naturally favour IPv6 communications over IPv4. For many customers, the cultural change this IPv6 preference brings to a desktop and/or server administrator is more than a little confusing, and definitely not something that should be enabled globally without some thought.

So, how do we provide the IPv6 capabilities required for DirectAccess manage out clients, whilst still preserving a more traditional IPv4 experience for other Windows systems?

The main way to solve this problem is to move away from using the global ‘isatap.domain.com’ DNS host record that is hard coded into all Windows Vista+ systems, and use a custom ISATAP router name that is specific to your environment. With this DNS host record created, all we need to then do is enable specific clients to use this custom ISATAP router name and we have a mechanism of controlling ISATAP on our terms.

Please Note: An alternate approach using HOSTS files is feasible for very small deployments, but this has limited scalability and does not allow for the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a DirectAccess cluster. Therefore this approach is not recommended outside of a lab environment.

In my opinion, the best way to achieve this technically is by way of Group Policy and a dedicated Windows security group for manage out clients, as follows:

Step 1: Create a Custom ISATAP DNS Record

Create a new DNS record called [something]isatap.domain.com, or similar. Configure this DNS record to point to the internal IP address of the DA server. If using a cluster, you will need to defined the record multiple times; once for each DA cluster member internal IP address, and once for the internal cluster VIP.

Please Note: As the ISATAP router name is customised, it will not be necessary to remove this name from the default DNS block.

Step 2: Create a Windows Security Group

Create a new Windows security group called DirectAccess Manage Out Clients, or similar.

Step 3: Create a New Group Policy

Using GPMC, create a new group policy object called DirectAccess: Manage Out Clients (Enable ISATAP) or similar, with the following properties:

image

Under the Scope tab, remove Authentication Users from the Security Filtering section and add the Windows security group created above; DirectAccess Manage Out Clients in our example.

image

Under the Details tab, set the GPO Status to User configuration settings disabled

image

Edit the newly created GPO and define the following settings:

Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies

ISATAP Router Name: Enabled

Enter a router or relay name: [something]isatap.domain.com

image

ISATAP State: Enabled

Select from the following states: Enabled State

image

Once completed, this should result in the following output in the Settings tab:

image

Step 4: Add Computer Accounts to Windows Security Group

All that now needs to be done is to add the computer accounts for machines that will be used for remote management of DirectAccess clients to the DirectAccess Manage Out Clients Windows security group.

Please Note: It will be necessary to reboot clients and servers after adding them to the DirectAccess Manage Out Clients windows security group before the new GPO will be applied.

Once this has been done, the specific manage out clients that you have defined by group membership should now receive ISATAP addressing and prefix information making them IPv6 capable.

Once configured correctly, you should receive a 2002:WWXX:YYZZ:8000:5efe:w.x.y.z format address (or similar) on the ISATAP adapter and will be able to remotely manage DirectAccess clients from this predetermined group of manage out machines.

Please Note: If the ISATAP adapter address assignment is not successful, it may also be necessary to use the following command to refresh the adapter state: sc control iphlpsvc paramchange

Hope this helps!

[This article has been adapted from a previous UAG DirectAccess blog post and hence screenshots may show UAG references which can be ignored]


Comments (29)

  1. Anonymous says:

    @Mika – Thanks!

  2. Anonymous says:

    @Steve – Correct #3 only. With regard to IPv6, the manage out clients (the ones initiating outbound connections from the intranet) need to be IPv6 capable which can be achieved using native IPv6 or ISATAP.

  3. Anonymous says:

    That is covered in the above text "…the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a DirectAccess cluster" – clients will then use the internal VIP as their IPv6 gateway to reach DA clients and NLB has the bi-directional affinity controls to allow for correct server determination on the way out

  4. Anonymous says:

    @Glenn – great news, thanks for the feedback!

  5. Anonymous says:

    What about Firewall Rules on the DirectAccess clients? Are any exceptions needed to allow ISATAP clients to reach the DA clients? For example, I want to ping a DirectAccess client. I'm on an ISATAP enabled computer. Do I need to make a Firewall rule on the DA client to allow ICMPv6 Echo and specify the ISATAP subnet as the Source network? Don't I also need to allow "Edge Traversal" for it to work over Teredo?

  6. Anonymous says:

    @DAsteven – correct, that configuration on the DA server is not necessary

  7. Anonymous says:

    @Cory – Hopefully the above comment answers your question too!

  8. Anonymous says:

    @Itismeap – Thanks! I don’t think so as it is stateless I believe; you could maybe try netstat to see the list of connections?

  9. Anonymous says:

    @Malte – the use of ISATAP with NLB is not officially supported and although Rob has a working config, we have seen customers raise support calls with problems.

  10. Anonymous says:

    @Tom

    To answer your questions… ISATAP is IPv6 encapsulated in IPv4 packets so you don't need an IPv6 native infrastructure to be able to use it. One limiting factor may be that your network devices between ISATAP enabled manage out box and DA servers (which by
    default operate as ISATAP routers) need to be able to pass protocol 41 (not port 41) check manufacturers spec for this… most will support it ! I've yet to find a big manufacturer that cannot support this..

    And the second question… ISATAP routers advertise the client routes that they service by design… so potentially you could have 3 DA clusters each with 2 servers and as long as they are all listed with isatap A records in DNS pointing at the IPv4 address
    of the inside interface of the DA servers (or the single interface if you have set up this way)
    If you had the above setup there would be 6 A records each with the IPv4 of each DA server.

    The ISATAP enabled manage out box will be served the routes for the potential client address space via ISATAP… so it will know that a client connected on cluster A, node A should go out via that specific node.. if you get my drift…. Now this might only
    go wrong if you have made the mistake of copying DA server settings policy between clusters… which would make each node A and B serve the same client address space.. .this would not be good…. each cluster must have its own unique IPv6 address space for
    manage out to work reliably.
    I have seen a few posting on the net where people have done this to speed a new cluster into service… not a good idea…..

    We use ISATAP in our organisation for manage-out and even though its not a "supported" way of doing this (MS prefer you to go native IPv6 now) it does still work admirably…..

  11. NLB says:

    If the DA server are under NLB, how would you manage out?  Thanks.

  12. Frosty says:

    Hi Jason,

    Just so I am 100% clear, which of the following need to be members of this limited ISATAP settings group?

    (1) the Direct Access clients themselves?

    (2) the Direct Access server?

    (3) the internal computers which want to be able to 'manage out' the clients?

    I am assuming that the answer is #3 only.  Have I understood correctly?

    Second question:  do I need to enable IPv6 on the internal computers, or can they continue to use IPv4 only?

    Thanks,

    Steve

  13. CorySeaman says:

    I am trying to clarification on this same question.  What exaclty requires ISATAP communication.  Does the NLS, DNS, email, and other support servers?

    From what I have been reading the GPO only requires members that are actually "pushing" out communications or iniitaing the connection to the DA clients. Is this correct?

  14. Thanks for the great info!

    If you do not want to reboot machines, you can refresh their computer group membership (by forcing them to request new Kerberos tickets) with command "klist -li 0x3e7 purge" prior to starting group policy processing with e.g gpupdate.

  15. Glenn Walton says:

    I was not able to manage out to DA clients and this article provided the silver bullet. Thanks for sharing this info!

  16. itismeap says:

    Great article. Is there a way to pull a list of all the ISATAP hosts that are 'connected' to the DA ISATAP server? We didn't control the ISATAP clients with a customer ISATAP hostname. We are going to remove the DNS entry now, but i'd like to see a list of clients which have connected so I can vet the list and add it to a security group for GP.

  17. Anonymous says:

    It's been a long time I did not publish something in the DirectAccess Challenge series . Let's

  18. Michael Babich says:

    For the systems in the custom ISATAP security group with the ISATAP Route enabled setting, when they attempt to communicate to systems on the intranet using the ipv4 address, how does that function? Since ipv6 is favored, will they attempt to route through the DA Box?

  19. Moto says:

    Jason, thank you for your post, but i cannot make this working
    1. I`ve created DNS record, type A which points to internal DA ipv4 interface (daistap.domain.com – 10.62.4.55)
    2. I`ve created GPO and membership
    3. After my SCCM receives the policy it shows: isatap enabled (ipv6 protocol disabled) fe80::5efe:10.62.4.110%12
    4. when i am trying to ping my DA ipv6 address – receives "transmit failed"
    What i am doing wrong? Please help…

  20. DAstevenB says:

    Jason nice article. Am I correct in thinking that the '[something]isatap.domain.com' does not also need to be stated on the DA server(s) with; [tag:netsh] interface ipv6 isatap set router [something]isatap.domain.com
    …but can remain as default 'isatap.domain.com' ?

  21. Anonymous says:

    Remote Management is one of the top feature provided by DirectAccess. By default a DirectAccess client

  22. AngB says:

    The Server 2012R2 Direct Access guidance states that ISATAP is no longer supported for 'manage out' scenarios. Does that include this limited ISATAP model?

  23. tom says:

    Thx for the great article, Jason. For me there have been 2 questions that are not 100% clear. We have a large infrastructure with multipe sites. There is the need so activate "manage out" to DA-clients for just a small part of the internal clients. So
    just to be clear, the ISATAP-traffic sent to the DA-servers is IPv4 or IPv6? Because in our infrastructure there would be no routing for IPv6, so if some Manage-Out-Clients are moving to another site there would be an IPv6-routing problem.
    In our infrastructure there will be multiple DA-servers with NLB, when for example one DA-client is conected with DAServer1 and there is an manage-out-request, how will the internal client find the right DAServer, or is there no need to route over the same
    DAServer the client is conected to?

  24. Malte S. says:

    Hello Rob,

    Could you clarify that for me: Should each DA NLB Cluster or each node of a DA NLB Cluster have its own GPO with a different IpHttpsPrefix?

    I have setup a two node DA NLB Cluster, in an IPv4-Only infrastructure but the manage-out over ISATAP is not working reliable since I have activated NLB. here is what I did:

    First I've created a single DA Server, Isatap worked very well
    Then I installed the NLB feature and enabled Load Balancing in the Remote Access wizard, ISATAP is still working very well.
    Then I added the second DA node to the Cluster: Directaccess itself works fine (failover takes about 4-5 pings in my lab), but manage-out over ISATAP only works if the client is connected to the first node or if the first node is in stoped state in NLB and
    all clients are failedover to the second node.

    Our ISATAP router is da-isatap.corp.com I have created 3 A Records (one for each node's IP Address and one for the Virtual IP of the NLB cluster). The DA servers are configured with one NIC.

    Malte

  25. Terrence says:

    Jason, we are trying to implement Directaccess manage out so we can manage our DA clients using SCCM. I have configured the following settings based upon this site,

    https://jeffreymaxan.wordpress.com/2014/10/23/directaccess-2012-and-manage-out-capabilites-without-ipv6-for-sccm-2012/comment-page-1/#comment-1 . However, my SCCM server does not receive an ISATAP IPv6 address. I was told ISATAP is being blocked in the
    DNS Global Query list, what issues would I face if I removed ISATAP from the Global Query list or should I troubleshoot elsewhere such as Windows Firewall,etc?

  26. @Terrance – No, DON’T enable ISATAP in the Global Query Block List otherwise you will provide ISATAP addresses to everything on your network that is looking for the default ISATAP DNS name (which is generally a bad idea). The GPO defined in my blog post
    allows you to define a custom ISATAP router name and then provide ISATAP router name that to specific hosts (management clients) by way of GPO filtering. I assume you have added the SCCM server to the ‘DirectAccess Manage Out Clients’ security group so it
    gets the correct ISATAP settings? I haven’t validated the steps in Jeffrey’s blog, but I do know the steps in mine do work.

  27. Terrence says:

    Jason, Thanks for reply. Yes, I have followed your blog post, including adding the SCCM server to the DirectAccess manage out security group. However, the SCCM server does not receive a IPv6 address for the ISATAP adapter. Also, there is no IPv6 record
    for the SCCM server in DNS.

  28. @Terrence – it sounds like an addressing problem not DA itself…follow the troubleshooting guidance here:
    https://technet.microsoft.com/en-us/library/ee844184(v=ws.10).aspx