DirectAccess leverages IPv6 transition protocols to enable clients to connect to the DirectAccess server when both are located on the IPv4 Internet. When the DirectAccess server is located in a perimeter or DMZ network behind a NAT device, only the IP-HTTPS IPv6 transition protocol is used. When the DirectAccess server is edge facing with public IPv4 addresses assigned to the external interface, the 6to4 and Teredo IPv6 transition protocols are also supported.
Note: It is generally recommended that the 6to4 IPv6 transition protocol be proactively disabled. More details here.
To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. When you configure DirectAccess for the first time, Teredo will automatically be configured if the installation detects the proper requirements for it. If you neglect to add the second consecutive public IPv4 address to the external network interface and configure DirectAccess, the installation will complete successfully without enabling Teredo support and Teredo will not appear in the list of services operations status, as shown here.
To enable Teredo support after you’ve configured DirectAccess, add the second consecutive public IPv4 address to the external network interface and then execute the following PowerShell command from an elevated command prompt.
Set-DAServer –TeredoState Enabled
Once complete, you’ll receive a warning message that states:
WARNING: Two consecutive IPv4 addresses have been detected on the Remote Access server, and Teredo is enabled. To use Teredo, ensure that internal servers allow inbound ICMP traffic.
Teredo requires that ICMPv4 Echo Requests be allowed inbound to any Intranet resource that a DirectAccess client will access. Ensure that all firewalls (host and network) are configured to allow ICMPv4 Echo Request inbound and outbound to ensure proper Teredo operation.
Once complete, close and then reopen the Remote Access Management console (in some cases a server restart may be required) to confirm Teredo support.
Pibi (@pibi73)
/ March 31, 2016Hi richard. i’m contact you to see if you can help me to solve a problem that is driving me crazy.
in a test environment I have a direct access server configured as follows:
servers in DMZ with two consecutive public ip, and 1 ethernet internal LAN:
when i use the notebook at home, the computer contact without problems direct access server; Teredo protocol is used and the computer surfing the Internet and contact all the corporate resources without problems.
the problem comes when the notebook is inside the corporate network. the laptop is connected only in IPHTTPS, not Teredo
if I give the command: netsh interface Teredo show state, I get:
type : enterpriseclient
server name :da.xxxx.it (group policy)
client refresh interval: 30 seconds
client port: unspecified
were: offline
error: incorrect server address.
the name server, da.xxxx.it in our internal dns has the AAA records pointing to the internal if of the direct access server.
in our internal dns we have a split domain: xxxx.local and xxxx.it. Of course the domain is xxxx.local and all computers and servers are in this domain.
as the last thing, I can tell you that in the dns servero option in the direct access : setup configuration in Infrastructure, i have :
xxxx.local with ipv6 dns server address and as only exception i havethe network location server and the public name of the direct access server da.xxxx.it
where is the error?
thanks again and in advance
Best regards.
Richard M. Hicks
/ March 31, 2016Teredo, or any other IPv6 transition technology for that matter, should not be required when your DirectAccess client is on the intranet. Because Teredo is configured as a type enterprise client, the interface is enabled but isn’t used for DirectAccess when you’re one the corporate network.
Pibi (@pibi73)
/ April 1, 2016Thanks Richard for the Thank you for the explanation.
just one last clarification. As AAA records of direct access serveri in the internal DNS, it’s better to have the ip of external or internal interface?
Thanks!
Richard M. Hicks
/ April 2, 2016Assuming you mean AAAA (quad-A) records, and yes, the internal interface only should be in internal DNS. No need for the external interface to register it’s IP address (IPv4 or IPv6) in DNS.
Chris Nicholls
/ February 6, 2017Hi Richard Hoping for some advice, i have built us a Teredo Connected DA Server 2016 from scratch everything is green tick and initial connection works on the W10 (Anniversary Update). However it appears after a reboot of the client it cannot connect in, i have managed to test through our Group Policies and there is only 2 polices on the client now 1 for the generation of Certs and the other being the Teredo DA Client GPO. After the reboot if i disable the Teredo and 6to4 adapter then re-enable them using Powershell it connects in. We are all completely baffled by this and appreciate any ideas to point us in the right direction.
Richard M. Hicks
/ February 8, 2017There are a number of operational challenges that Teredo has, this being one of them. In my experience the client’s choice of IPv6 transition technologies leaves quite a bit to be desired. This may be a bug in the Windows OS, so you’ll probably have to engage with Microsoft support to identify the root cause. They might also have a private hotfix to address the issue.
Chris Nicholls
/ February 9, 2017OK thanks Richard, just wanted to make sure we had not missed anything obvious on it.