From a client perspective, DirectAccess is an IPv6-only solution and requires IPv6 connectivity end to end. To enable the solution to work on IPv4-only networks, DirectAccess makes use of one of several IPv6 transition technologies – 6to4, Teredo, or IP-HTTPS. By leveraging these IPv6 transition technologies, a DirectAccess client can communicate with the DirectAccess server when they are both connected to the public IPv4 Internet, which is the most common deployment scenario today.
The first two IPv6 transition technologies, 6to4 and Teredo, both require that the DirectAccess server be directly connected to the public Internet. Beginning with Windows Server 2012, placing the DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is now supported. However, in this deployment model only the IP-HTTPS IPv6 transition protocol can be utilized. In this scenario, it is recommended to disable the unused IPv6 transition protocols to prevent potential connectivity issues. You can disable them on a per-host basis using PowerShell, which is fine for individual client testing purposes, or globally using Active Directory Group Policy Objects (GPOs), which is recommend for enterprise-wide production deployment.
To disable unused IPv6 transition protocols on a per-host basis on Windows 8 clients using PowerShell, open an elevated PowerShell prompt and execute the following commands:
Set-Net6to4Configuration –State disabled Set-NetTeredoConfiguration –Type disabled Set-NetIsatapConfiguration –State disabled
To disable unused IPv6 transition protocols on a per-host basis on Windows 7 client using netsh, open an elevated command prompt and execute the following commands:
netsh interface 6to4 set state disabled netsh interface teredo set state disabled netsh interface isatap set state disabled
To disable unused IPv6 transition protocols using Active Directory GPO, open the Group Policy Management Console (GPMC) and create a new GPO. Edit the GPO by navigating to Computer Configuration / Policies / Administrative Templates / Network / TCP/IP Settings / IPv6 Transition. Double-click Set 6to4 State and enable the policy, then select Disabled State from the list of states. Repeat these steps for Teredo and ISATAP.
Change the security filtering for the GPO and specify the security group for your DirectAccess clients. Once complete, link the new GPO to the domain.
As a reminder, the steps above are for disabling unused IPv6 transition protocols in a deployment scenario where the DirectAccess server is running Windows Server 2012/R2 and is deployed behind a NAT device. If your DirectAccess server is connected directly to the public Internet, disabling these IPv6 transition protocols is not required.
Jon Rodriguez
/ August 28, 2013Great post, Rich! Server 2012 allowing for deployment of DA behind the edge definitely increases the value proposition of DA. Disabling all other trans. protocols should be a no-brainer from a “maximum hardening” standpoint, but I’d wager it gets skipped over more often than not.
Richard Hicks
/ August 28, 2013Thanks Jon. 🙂 This configuration is primarily to reduce or eliminate some potential conflicts that arise with some of these transition technologies. However, you are absolutely right that it is a good idea from a security perspective as well. The general guidance from a security perspective is to disable or remove any services that aren’t being used to reduce the attack surface on the system. Disabling unused IPv6 transition technologies certainly falls in to that category.
Cuq!
/ December 4, 2013Richard, Thanks for this post! It has finally fixed an issue I’ve been facing recently with a brand new DirectAccess 2012 deployment. Very simple configuration, pretty much out of the box with a server in the edge, 2 nics, IP-HTTPS, self signed certifcates, DNS configured, and clients connecting like a charm. Suddenly I noticed that “startup scripts” were not running, not only when the client was connected through DirectAccess but also when they were physically connected to the LAN into the office. It seems like as soon as the GPO got deployed, the clients were facing some delays to reach the network shares (\\domain\netlogon in this case) and therefore the scripts. I found a few event logs showing a “DNS timeout” trying to resolve ISATAP.domain.com. which actually was never enabled. It seems like after disabling the rest of the protocols, the startup process runs slightly quicker, no errors are shown in the event viewer, and scripts run as expected. I would definitely suggest everybody to give it a try if they are facing startup issues or slowness.
Cuq!
/ December 4, 2013Richard, Thanks for this post! It has finally fixed an issue I’ve been facing recently with a brand new DirectAccess 2012 deployment. Very simple configuration, pretty much out of the box with a server in the edge, 2 nics, IP-HTTPS, self signed certifcates, DNS configured, and clients connecting like a charm. Suddenly I noticed that “startup scripts” were not running, not only when the client was connected through DirectAccess but also when they were physically connected to the LAN into the office. It seems like as soon as the GPO got deployed, the clients were facing some delays to reach the network shares (\\domain\netlogon in this case) and therefore the scripts. I found a few event logs showing a “DNS timeout” trying to resolve ISATAP.domain.com. which actually was never enabled. It seems like after disabling the rest of the protocols, the startup process runs slightly quicker, no errors are shown in the event viewer, and scripts run as expected. I would definitely suggest everybody to give it a try if they are facing startup issues or slowness.
Anwar Mahmood
/ November 25, 2014Can this | should this be done on the DirectAccess server (simple, single server setup, IP-HTTPS) too? I *hate* seeing so many virtual, unused NICs in IPCONFIG.
Richard Hicks
/ December 3, 2014In theory, yes. However, I’ve not tested this so I’m not sure if it would cause any other issues. 🙂
Anwar Mahmood
/ December 3, 2014Thanks for your reply. I haven’t tested this either.
Interestingly, the following book:
Practical IPv6 for Windows Administrators
author: Edward Horley
ISBN-10: 1430263709
ISBN-13: 978-1430263708
states:
Best practices are to leave IPv6 ON but to disable all transition technologies. Specifically, turn off 6to4, ISATAP, and Teredo on both Windows Server and Client hosts.
Kind regards,
Anwar
Richard Hicks
/ December 3, 2014That’s correct. However, the DirectAccess role is a unique one with regards to IPv6, as it acts as a gateway between IPv6 and IPv4 networks. For this reason, disabling these transition protocols, even if they aren’t being used, may cause problems. I can’t say this for certain as I haven’t tested it, but it is possible that disabling unused IPv6 transition protocols on a DirectAccess server may cause some alerts to be raised in the Remote Access Management console. If you’re not using ISATAP, 6to4, or Teredo, I’d suggest disabling them and we’ll see what happens. 🙂 I’ll certainly test this out when time permits and report back here if I see something unexpected.
spadge007
/ February 17, 2015I am troubleshooting some Manageout issues and noticed that clients do not publish their ipv6 addresses to DNS. However, the DA servers 6to4 address is published to DNS. We do not use private IP addresses on our Internal networks. Using Group Policy I have set the 6to4 state to disabled on our Windows 7 clients. I am wondering if I should disable the 6to4 adapter on the DA server also. The DA Server is running Server 2012 R2, dual NIC implementation.
Richard Hicks
/ February 21, 2015I would definitely disable the 6to4 IPv6 transition protocol for all of your internal clients. It shouldn’t be necessary to disable it on the DirectAccess server, but you can certainly give it a try. ISATAP should still work with non-private IP addresses.
TridentMilSys
/ March 1, 2016I know this blog topic has been quiet for a while, but I’m hoping someone is still listening… I disabled 6to4, Teredo, ISATAP, and IP-HTTPS technologies through Group Policy on a 2012 R2 Domain Controller. This server is not a DirectAccess server, but one that I need to secure. Although these are not the only changes I made, I’ve found that with ISATAP and Teredo disabled, the server will boot and consider itself to be in a Public network location as opposed to a domain location. There are several things I can do to “fix” it after the boot: disable and re-enable the NIC or restart the Network Location Awareness (NLA) service, for examples. These “fixes” make me think there is a timing issue involved.
Once I re-enable ISATAP and Teredo technologies, the server will boot and come up in the domain location. I have a second domain controller that exhibits the same behavior. However, as long as one DC is up and running and not in a Public location (so the firewall doesn’t block most traffic) when the other boots, then the second DC to boot will come up in the domain location as well.
The problem of 2012 DCs coming up to a Public location is talked about quite often on the internet, but never with regard to the IPv6 transition details, and I’ve tried several suggestions that have worked for others, including: Changing the NIC bind order (advanced adapter properties), manually setting the DNS suffix on the adapter, and disabling IPv6 using the DisabledComponents registry setting. In my situation, so far, the only consistent solution is to re-enable ISATAP and Teredo. I could consider setting the NLA service to delayed start, but I’m not sure of the side effects of doing so. I could also run a script that restarts that service after some small period of time after boot, but that feels like an unnecessary and potentially harmful solution.
Any thoughts are greatly appreciated!
Richard M. Hicks
/ March 3, 2016Hi Jerry,
The focus of this article relates specifically to disable IPv6 transition protocols for clients provisioned for DirectAccess. Disabling these transition protocols for other Windows servers and clients is also an excellent idea for a variety of reasons. However, I don’t have any experience to share with you regarding potential side effects such as you are experiencing. If anyone else has some guidance perhaps they’ll comment. 🙂
TridentMilSys
/ March 11, 2016Hi Richard,
Thanks for the reply. Yes, I know my post was a little off topic, but I’m hoping one of your readers might have experienced the symptoms I’m seeing and could offer a suggestion.
Take care!
cubanitguy
/ November 2, 2016Hello Richard, I am working on configuring Direct Access at my with my Windows 2012 R2 Direct Access Server residing in the DMZ one Single NIC.
Per https://technet.microsoft.com/en-us/library/jj134148.aspx#1.2%20Plan%20firewall%20requirements, we opened the following firewall ports and protocols to evaluate the Microsoft Direct Access offering.
Teredo traffic-User Datagram Protocol (UDP) destination port 3544 inbound, and UDP source port 3544 outbound.
6to4 traffic-IP Protocol 41 inbound and outbound.
IP-HTTPS-Transmission Control Protocol (TCP) destination port 443, and TCP source port 443 outbound.
However, when configuring Step 2 (Remote Access Server) and select ‘Behind an edge device (with a single network adapter)’, enter the public name and click Next I receive the error below when selecting my internal network adapter (Ethernet0) – ‘IPv6 is not enabled on the external network adapter of server Ethernet0. Enable IPv6 or select an alternate adapter. IPv6 is disabled on my server but when I enable IPv6 on my network adapter and retry the Remote Access Server Setup throws up the error below.
‘The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol’
Any assistance will be grrrrreatly appreciated! Thanks! Juan
Richard M. Hicks
/ November 5, 2016First, when your DirectAccess server is in a DMZ behind a NAT device, the only thing that needs to be allowed inbound to the DirectAccess server is TCP port 443. You do not need to allow ports for 6to4 or Teredo. In fact, they should be proactively disabled on your clients as described here.
With regard to IPv6, it must not be disabled on the DirectAccess server or clients. Simply checking the box for IPv6 in the network interface bindings is not sufficient. It must also not be disabled via the registry. Be sure to check HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents. If this exists and is set to anything other than “0”, change it to 0 and restart. 🙂
cubanitguy
/ November 7, 2016Thanks Richard! Yeah, I tried adding that registry key and setting it to 0 as it was not there. However, I am still receiving the same “The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL wqs not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.” It’s weird…
Thanks,
Juan
Richard M. Hicks
/ November 7, 2016Not sure what’s up then. I might suggest provisioning a new server from scratch and see if you have that issue. As a precaution, you might want to prestage a computer account in a dedicated OU with inheritance blocked just to eliminate the change of a group policy setting interfering with DirectAccess.
cubanitguy
/ November 7, 2016That’s my next move. Thanks again for your help. Also, your course on Pluralsight is fantastic!
Juan
Richard M. Hicks
/ November 7, 2016Thanks! I’m hoping to have an updated course for Windows Server 2016 available in a few months. Stay tuned!
blubberdiblub
/ February 10, 2018Thanks for the paths to the group policy settings. This is tremendously useful, as I have found that group policy items will persist across each and every updates on my Windows 10 Pro desktop machine, whereas normal settings usually get reset during bigger updates (the ones that need to restart, take a long time and sport that greeting as if you just installed freshly).
JP Greyling
/ November 7, 2018Good Day Richard, thank you for your contribution. I have been following your Pluralsight video on DirectAccess and the only diffrenece in my setup is that I use only 1 network card on my DA server. The issue I am having is a funny one, I can ping my da hostname (da.mytraininglab.com) with the computer not joined to the domain. The moment I join it to the domain and then apply the DA GPO, when I connect it to a public network then when I try to ping da.mytraininglab.com. it says hostname not found but I can ping\resolve it by -4 at the end to force it to ping on IPv4. nslookup also works fine, the only issue I am having is that I can’t disable 6to4, I tried Local GPO on the laptop as well as powershell. Do you know why the PC will try and resolve the hostname using IPv6 and not IPV4?
Richard M. Hicks
/ November 9, 2018It sounds like perhaps the FQDN da.mytraininglab.com is not excluded from your NRPT. If you are using split DNS (mytraininlab.com is both your internal and external domain) you’ll need to exclude the DirectAccess public hostname as described here: https://directaccess.richardhicks.com/2017/12/26/directaccess-nrpt-configuration-with-split-dns/.