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 internal network, the DirectAccess servers uses 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.
ISATAP
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 technology 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.
ISATAP can be 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.
Important note: It is not recommended to deploy ISATAP globally via DNS. See below for more details.
When configured and enabled, ISATAP opens up new and interesting network communication scenarios. For example, a helpdesk administrator 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”.
Limitations
In the early days of DirectAccess with Windows Server 2008 R2 and Forefront UAG, configuring and enabling ISATAP 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 internal 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, ISATAP 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, ISATAP routing will cease to function, which is fundamentally backward.
Targeted Deployment
As I mentioned earlier, ISATAP is a global setting by default. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the internal network to remote 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 recommended 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. A unique ISATAP hostname (for example, DirectAccess-ISATAP) is created in the internal DNS that resolves to the internal IPv4 address of the DirectAccess server. Create a new GPO in Active Directory to assign it to management workstations using security group filtering or OU targeting. Edit the GPO setting Computer Configuration > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies > Set ISATAP State (Enabled and set to Enabled State) and > Set ISATAP Router Name (Enabled and enter the ISATAP hostname created previously).
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, open an elevated PowerShell command window and run the following command:
Set-NetISATAPConfiguration -Router <NameOrIPAddress>
Netsh
Another command line method for configuring the ISATAP is to use netsh.exe. In an elevated command prompt window run 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 ISATAP 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.
Supportability
ISATAP is only supported for single server DirectAccess deployments. ISATAP will work when Network Load Balancing (NLB) is enabled, but it requires some additional configuration. ISATAP does not work when an external load balancer is in use and/or multisite is enabled. To restore manage out functionality for DirectAccess for load-balanced and multisite deployments, additional infrastructure and configuration is required. Fill out the form below to request more information.
Summary
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 ISATAP configuration. Choose the one that works best for you and have fun managing your DirectAccess clients!
Additional Information
DirectAccess Manage Out and Microsoft System Center Configuration Manager (SCCM)
DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out
DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016
Contact Me!
Want to enable DirectAccess manage out for System Center Configuration Manager (SCCM) remote control or Remote Desktop Connection (RDC) in load-balanced and multisite deployments? Fill out the form below for more information.
ipxfer
/ July 11, 2013Thanks 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.
Richard Hicks
/ July 12, 2013Your issue is likely related to a name resolution issue for the ISTAP DNS host record. For ISATAP with NLB, you must register not only the NLB VIP, but the dedicated IP addresses (DIPs) for each node in the NLB array. More details here:
http://technet.microsoft.com/en-us/library/jj134148.aspx
Thanks to Jason Jones for clarification on this point! 🙂
Casey Brennan
/ August 1, 2013It appears that the Troubleshooting Portal URL was removed from the DCA 2.0 group policies — can you confirm that? Was nice to have that.
Richard Hicks
/ August 2, 2013Confirmed. 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.
Casey Brennan
/ August 6, 2013Thank 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.
Cory
/ September 9, 2013Thanks 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
Richard Hicks
/ September 10, 2013Any 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.
Cory
/ September 10, 2013Richard,
Thanks this does clarify things a little.
So if I don’t have any “managed out” servers then do I need ISATAP at all?
Richard Hicks
/ September 18, 2013That’s correct. Unless you have a specific need to *initiate* outbound communication to at DirectAccess client there’s no need for ISATAP.
itismeap
/ March 11, 2014If 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
Richard Hicks
/ March 24, 2014I don’t know of a way to do this, unfortunately.
Andrew
/ April 24, 2014Perhaps 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?
Richard Hicks
/ April 25, 2014With 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: http://directaccess.richardhicks.com/2013/06/19/network-interface-configuration-for-multihomed-windows-server-2012-directaccess-servers/
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
Andrew
/ April 26, 2014Thanks 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!.
Richard Hicks
/ May 5, 2014Largely 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.
Frédéric Barbier
/ October 8, 2014It 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
Richard Hicks
/ October 20, 2014Not 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.
Michael Wieland
/ October 31, 2014Hi 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?
Richard Hicks
/ November 3, 2014Does the DirectAccess server have a global address on it’s ISATAP interface?
Michael
/ November 4, 2014What 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.
Richard Hicks
/ November 7, 2014The 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, 2014Hi 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 :-(.
Richard Hicks
/ November 10, 2014Try 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.
Darren
/ February 2, 2015I 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?
Richard Hicks
/ February 2, 2015On 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!
spadge007
/ February 2, 2015Hi 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.
Richard Hicks
/ February 2, 2015You 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.
spadge007
/ February 12, 2015Hi 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?
Richard Hicks
/ February 12, 2015You’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.
spadge007
/ February 17, 2015Many 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.
Richard Hicks
/ February 21, 2015Good 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!).
Larson
/ August 4, 2015We 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?
Richard Hicks
/ August 8, 2015ISATAP 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. 🙂
John
/ December 9, 2015It would be great to see a blog post on configuring ISATAP using an external ISATAP server. Are you doing this with WIndows Server?
Richard M. Hicks
/ December 11, 2015Yes, 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. 🙂
Gus
/ March 10, 2016I’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?
Richard M. Hicks
/ March 11, 2016ISATAP 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.
Adam
/ April 6, 2016Hi 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
Richard M. Hicks
/ April 6, 2016Drop me a note and I’ll explain more then. 🙂
Julie Basler
/ February 23, 2017Asking 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
Richard M. Hicks
/ February 27, 2017Implementing 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.
Jason
/ April 13, 2016I’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. 🙂
Richard M. Hicks
/ April 13, 2016The best way to ensure that ISATAP is removed completely is to remove the ISATAP record from DNS (sounds like you’ve done this) and then also disable the ISATAP IPv6 transition technology globally using group policy. Details here: https://directaccess.richardhicks.com/2013/08/27/disabling-unused-ipv6-transition-technologies-for-directaccess-clients/.
Bryan
/ December 20, 2016My 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
Keith Krus
/ July 18, 2017I have inherited a Direct Access 2012 R2 server that actively serves approx 30-70 clients at any given time throughout the production day. I am running into a intermittent “connecting” issue with DA clients. DA will not be in a “connected” state. It simply says “connecting” and I can’t seem to find a rhyme, reason, nor a common denominator. Then all of a sudden DA will connect with either a restart or time. Random clients, random times. I have been reading that on domain controllers simply removing “isatap” from the GlobalQueryBlockList registry key should help resolve the issue I am experiencing. What are your thoughts?
http://gerryhampsoncm.blogspot.com/2014/11/intermittent-issue-with-direct-access.html
Richard M. Hicks
/ July 20, 2017Removing ISATAP from the global query block list is not recommended in most situations. I’m not sure what the problem was in your environment without digging in to the details, but I can assure you that enabling ISATAP was not the best choice. That said, if you are happy with it and there aren’t any negative side effects, sometimes its better to accept things as they are and move on to fight another battle. 😉
Matt
/ March 9, 2018Hi Richard, I’ve setup a server as an ISATAP router We currently have two DA servers. We now have isatap on a separate server (not on the DA servers). I assume we have to create routes to each? When I had isatap on the DA server itself, everything seemed to work easily.. However, to not have isatap on the DA server, I’m trying to figure out how to route traffic to each of the DA servers. Any pointers? Thank you much, Matt
Richard M. Hicks
/ March 10, 2018Correct. If you are setting up a separate ISATAP routing server you’ll have to define IPv6 routes accordingly.
Franz Schenk
/ March 25, 2020Thank you for this helpful post. We implemented this solution with success in several 2012 R2 DA installations. But according our experience, ISATAP does not work anymore on a DA Server 2019. On Server 2019, there are no longer visible ISATAP interfaces in the device manager (with “show hidden devices” enabled). And despite get-NetIsatapConfiguration shows that the ISATAP router is enabled, it does not work. ipconfig still shows two isatap interfaces, but both have only one IPv6 link local address.
Have you ever tested ISATAP on server 2019?
Richard M. Hicks
/ March 26, 2020I have configured ISATAP with Windows Server 2019 and it works, for the most part. I’ve had a few challenges with the ISATAP tunnel adapter persisting after reboot, but nothing that couldn’t be fixed with a PowerShell script set to run after restart. 🙂
Alain le Sage
/ March 29, 2020Mind sharing the script with us? I’m trying to get ISATAP running on 2019, but can’t get it to work.
Richard M. Hicks
/ March 30, 2020Here you go! https://github.com/richardhicks/directaccess/blob/master/Reset-DaIsatapConfiguration.ps1
Franz Schenk
/ March 31, 2020Thank you for the script. But it doesn’t work on our DA server:
PS C:\Windows\system32> &”C:\Users\adm_smartit\Desktop\reset-isatap.ps1″
Set-NetIPInterface : Cannot validate argument on parameter ‘InterfaceIndex’. The argument is null. Provide a valid
value for the argument, and then try running the command again.
At C:\Users\adm_smartit\Desktop\reset-isatap.ps1:50 char:36
+ Set-NetIPInterface -InterfaceIndex $IsatapInterfaceIndex -Forwarding …
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Set-NetIPInterface], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Set-NetIPInterface
Have debugged the script. The values of $InternalInterface and $InternalInterfaceGuid are correct. But the variable $IsatapInterfaceIndex is empty.
Have then tried to to replace the $IsatapInterfaceIndex Variable with the correct ifIndex value. But the command throws a Windows System Error 87
Set-NetIPInterface -InterfaceIndex 13 -Forwarding Enabled -Advertising Enabled
Set-NetIPInterface : The parameter is incorrect.
At line:1 char:1
+ Set-NetIPInterface -InterfaceIndex 13 -Forwarding Enabled -Advertisin …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (MSFT_NetIPInter…ystemName = “”):ROOT/StandardCimv2/MSFT_NetIPInter
face) [Set-NetIPInterface], CimException
+ FullyQualifiedErrorId : Windows System Error 87,Set-NetIPInterface
Richard M. Hicks
/ March 31, 2020Sorry about that. I’ve used that script a few times without issue. However, it hasn’t been fully tested across all platforms. What version of Windows Server are you running? And is it single-NIC or dual?
Franz Schenk
/ March 31, 2020Thank you, I still hope that your script helps to find the problem.
It’s a 2019 server version 1809 with the latest updates installed. The DA Server has two NIC.
Have posted this problem to the IPv6 Technet forum a week ago. There is not any helpful advice there, but two other users that have the same problem with server 2019.
Richard M. Hicks
/ March 31, 2020Ok, that’s odd. I developed this script on Windows Server 2019 specifically for a customer having issues with Windows Server 2019. I though perhaps if you were running something older like Windows Server 2012 R2 that perhaps I’d overlooked something. I don’t recall if I tested this on Windows Server 2012 R2. It should definitely work for 2019 though. :/
Sergei E.
/ April 16, 2020Hello Richard, thank you for the script. It works fine on the Windows Server GUI, but it doesn’t work on the CORE version, because the isatap interface is represented as FQDN. I want to suggest replacing part of your script:
$InternalInterface = Get-RemoteAccess | Select-Object -ExpandProperty InternalInterface
$InternalInterfaceGuid = Get-NetAdapter -InterfaceAlias $InternalInterface | Select-Object -ExpandProperty InterfaceGuid
$IsatapInterfaceIndex = Get-NetAdapter -IncludeHidden | Where-Object Name -eq “isatap.$InternalInterfaceGuid” | Select-Object -ExpandProperty ifIndex
on:
$IsatapInterfaceIndex = (Get-NetAdapter -IncludeHidden | where {$_.Name -Like “isatap*”}).ifIndex
As a result, the script runs on all versions of Windows Server with the same network interface.
As a result, the executed part of the script looks like this:
$InternalIPv6Prefix = Get-RemoteAccess | Select-Object -ExpandProperty InternalIPv6Prefix
$IsatapInterfaceIndex = (Get-NetAdapter -IncludeHidden | where {$_.Name -Like “isatap*”}).ifIndex
New-NetRoute -AddressFamily IPv6 -DestinationPrefix $InternalIPv6Prefix -InterfaceIndex $IsatapInterfaceIndex -Publish Yes -ErrorAction SilentlyContinue
Set-NetIPInterface -InterfaceIndex $IsatapInterfaceIndex -Forwarding Enabled -Advertising Enabled
Richard M. Hicks
/ April 17, 2020Thanks for sharing this, Sergei. I’ve tested this extensively on Windows Server Core and it works without issue for me. I do see that when I first spin up the VM it has an ISATAP interface in the form of ISATAP.FQDN, but after joining the domain it reverts to ISATAP.{GUID}.
Can you tell me what version of Windows Server Core you are running? Also, do you have one network interface or two?
FYI, your suggestion to use the -Like “*isatap*” won’t work because it will match both ISATAP tunnel adapters for dual-NIC deployments. The script needs to be able to distinguish between the internal and external interface when two NICs are configured.
I’ll continue to investigate though and see what I can find. 🙂
Richard M. Hicks
/ April 17, 2020One more question…how are you configuring the IP address on your server? Static? DHCP?
Sergei E.
/ April 17, 2020>Can you tell me what version of Windows Server Core you are running? Also, do you have one network interface or two?
>how are you configuring the IP address on your server? Static? DHCP?
OS Name: Microsoft Windows Server Standard
OS Version: 10.0.18363 N/A Build 18363
Original Install Date: 12/12/2019
System Boot Time: 4/16/2020
System Model: Virtual Machine
Hotfix(s): 11 Hotfix(s) Installed.
[01]: KB4537572 [07]: KB4528759
[02]: KB4497165 [08]: KB4538674
[03]: KB4513661 [09]: KB4541338
[04]: KB4517245 [10]: KB4552152
[05]: KB4521863 [11]: KB4549951
[06]: KB4524569
Network Card(s):1 NIC(s) Installed
[01]: Microsoft Hyper-V Network Adapter
Connection Name: Ethernet
DHCP Enabled: No
IP address(es)
[01]: 10.xxx.xxx.xxx
[02]: fe80::xxxx:0:xxxx:xxxx
[03]: fd31:xxxx:xxxx:3333::1
In my tests, all versions (not important GUI or CORE) of Directaccess after version 2016, after restarting the server, resets the isatap interface settings.
I always installed Directaccess on a VM with a single network interface, the number of Directaccess clients is small, with Windows 10 OS.
Richard M. Hicks
/ April 18, 2020So you are running Windows Server 1903 Semi-Annual Channel (SAC) release. I’ll do some testing with that specific version and see what I can find. I agree, Windows Server 2016 and later will not maintain ISATAP settings after reboot. It’s the reason why I wrote this script. 🙂 What I’m trying to do is reproduce the issue you are having. I’ll continue testing and make changes to the script as required.
Sergei E.
/ April 18, 2020Hello Richard, on Windows Server Core via regedit I deleted the DNSDomain prefix, after restarting the server, the isatap interface is displayed as isatap.GUID. Where the prefix came from, I’m not sure now.
Franz Schenk
/ May 1, 2020Because we couldn’t bring up the ISATAP router at all on our 2019 DA server even with your script, we opened a PSS Call for this issue.
We really tried to insist, but Microsoft is extremly unwilling to provide any support, they write that ISATAP is no longer supported at all on server 2019, regardless of all Microsoft documentation that states otherwise.
Some quotes from the Microsoft support engineers:
– “Per reccommondation of our escalation engineers I need to inform you again that ISATAP is not recommedend to be used in Direct Access. Instead NAT64 or Native should be used. The article clearly states that ISATAP will automatically configure itself. But still if the router doesn’t work properly, it is not supported.”
– “We have confirmed internally that public article will be changed/updated and this will take some time. The goal you are trying to achieve is not supported by Microsoft.”
Richard M. Hicks
/ May 1, 2020Not surprising. I have many customers still using ISATAP for manage out and it still works well, albeit not formally supported. I’m sure at some point it will cease to function, but for now it is still providing crucial functionality for many organizations. 🙂