DirectAccess and Teredo Adapter Behavior

In a recent blog post about an interesting problem we had with understanding Outlook performance issues and the IP-HTTPS adapter, we had the opportunity to review how the various IPv6 transition technology adapters worked in terms of when they were enabled and when they were disabled. If you haven’t seen that post, head on over to The Mystery of the IP-HTTPS Listener, an Outlook Client and an IPv4 Only Network at https://blogs.technet.com/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx One of the things that we got a better understanding of was Teredo adapter behavior. First, Teredo is an IPv6 transition technology that is used by DirectAccess clients when they are located behind a NAT device, and thus are typically assigned a private IP address (RPC 1918). Teredo encapsulates the IPv6 packets in an IPv4 packet with a UDP header. The UAG DirectAccess server listens for connections from Teredo clients on UDP port 3544. Therefore, if the DirectAccess Teredo client has outbound access to the UAG DA server’s UDP port 3544, the Teredo connection can be established. However, before that Teredo connection can be established, the adapter needs to be configured. When you run the UAG DirectAccess Wizard, one of the many things it does it configure a DirectAccess clients Group Policy Object (GPO). The DA Clients GPO (The actual name of the GPO is UAG DirectAccess: Client [GUID] ) contains settings for the IPv6 transition technologies used by the UAG DirectAccess clients, and one of these is the Teredo client configuration. If you go to the following path: Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies you will find Teredo GPO configuration options, as seen in the figure below. Figure 1 There are two settings that are of the most interest to us. The first one is the Teredo Default Qualified setting, as seen in the figure below. The UAG DirectAccess Wizard leaves this setting at its default. As you can see in the description, “qualified” means that the Teredo interface is ready to communicate. The default setting is Enabled State, which means that the Teredo adapter will go through the process of trying to connect to the UAG DirectAccess server to obtain information required to communicate. Qualification includes determining what type of NAT device the Teredo client is located behind. Figure 2 The second setting of interest is the Teredo State setting. The UAG DirectAccess wizard leaves the Teredo State at its default setting. The default setting is to set the Teredo state as Client. With this state enabled, the Teredo adapter will come up only if the DirectAccess client is not on a network that has a domain controller on it. If the DirectAccess client detects that it’s on a network with a domain controller, it will disable the Teredo adapter, and the IP-HTTPS adapter will take over, assuming that the IP-HTTPS adapter can establish a connection with the UAG DirectAccess server’s IP-HTTPS listener. Figure 3 Now the celebrity question is “how does the DirectAccess client determine is there is a domain controller on the network?” That’s a great question, and it’s not easy to find an answer to it. At least it wasn’t easy, until this article was published. To determine if the DirectAccess client is on a “managed network”, the client performs a DNS query looking for SRV records in the path  _ldap._tcp.dc._msdcs.DnsDomainName, where DnsDomainName is the name of the DNS suffix assigned to the current connection. If SRV records are located, the client assumes it is in a managed network, and Teredo is disabled. If no records are located, the Teredo interface is enabled. What’s important to know here is that the detected domain can be any domain. It does not need to be the domain that the computer belongs to. Given this to be the case, a DirectAccess client that’s connected to a home network with a domain (a lot of us computer geeks have domains on our home networks) or to a customer’s network that has domain controllers on it, if a DNS query for that SRV record is successful, the Teredo adapter will disable itself when the “Client” state is enabled for the Teredo client. Another important thing to know is that the DA client doesn’t need to connect to the domain controller, it only needs to be able to resolve the name. As you can imagine, this might cause some problems. For example, suppose you connect to your corporate network from your domain-based home network (that’s my situation – I work from home and connect to the Microsoft corpnet over DirectAccess). Because my corporate laptop is connected to a domain-based network, it will detect a domain, and disable the Teredo adapter. In this situation, my Teredo adapter will be disabled and I’ll be forced to use IP-HTTPS, which is a lower performance adapter. Most users would prefer a higher-performance solution (including me), so is there anything we can do about that? Yes there is – but you’ll need to customize your Group Policy. In Figure 3 , notice that there is another option for setting the Teredo State – that option is Enterprise Client. When you set the Teredo State to Enterprise Client, the Teredo interface will always be present, even if the host is on a network that includes a domain controller. Now, the Teredo adapter will try to activate even when a domain (managed network) is detected. MSIT decided to do this, as evidence by the figure below. Here you can see the output of the netsh interface teredo show state command. Notice that the State is set as qualified – which means that the adapter was able to determine what type of NAT device it was behind, which involves being about to connect to the UAG DirectAccess server. Also, notice the Network setting, which reports as managed. This combination shows that the Teredo adapter was able to connect to the UAG DirectAccess server, it detected a domain network, but remains activated and functional because the Type is set as enterpriseclient (Group Policy) . Figure 4 I need to point out before moving on that if you make these “hand edits” to the UAG DirectAccess Wizard GPO, that they will be overwritten the next time you use the UAG DirectAccess Wizard to update the DirectAccess Client GPO. So you’ll need to create a change control reminder that you need to manually set the Teredo State to Enterprise Client. Now, while this is a good thing for those of us who want to connect from managed networks (successful domain detection), it does have the potential to cause problems. One example of this is when NLS (Network Location Server)failure takes place, NLA (Network Location Awareness) isn’t able to succeed at domain detection for setting Windows Firewall with Advanced Security (WFAS), with an end result being the WFAS Profile is set to Public or Private (which enables the DirectAccess Connection Security Rules), and the network firewall allows outbound access to UDP port 3544 to the IP address on the external interface of the UAG DirectAccess server. In this scenario (admittedly uncommon) the Teredo adapter will be enabled and intranet communications will take place through the UAG DirectAccess server. However, given how common domain networks are, and how uncommon the combination of events noted above are, it makes sense to make the default Teredo State Enterprise Client. Cannot Reach the DirectAccess Server with Teredo https://technet.microsoft.com/en-us/library/ee844188(WS.10).aspx Author: Tom Shinder, Technical Writer tomsh@microsoft.com Technical Contributor : Yaniv Naor, SDE, DA

Comments

• Anonymous
  December 12, 2013
  One way to force the enterpriseclient state is to create a separate GPO with higher link order in the same OU as the UAG-generated GPOs. This GPO will then be processed last and thus overwrite state=default with state=enterpriseclient. Cheers Rolf