Solving a DirectAccess Client Blocked 6to4 Connection

Pat Telford recently shared with me an interesting case of a DirectAccess client that was assigned a public IP address, but wasn't able to connect to the UAG DirectAccess server because the ISP was blocking 6to4 traffic.

The client system was a laptop using a Sprint WiMax connection. The laptop was assigned a public IP address, and because of this the 6to4 adapter came up. However, because the 6to4 connection couldn't be established (maybe because IP Protocol 41 was blocked?), the Teredo adapter came up (for more information on what causes the IPv6 transition technology adapters to come up and down, see my post at http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx).

However, since the tunnel endpoints defined for the DirectAccess IPsec tunnels are 6to4 addresses, the client preferred to use the 6to4 adapter, in spite of the fact that the 6to4 connection couldn’t be established and the Teredo connection was successful. So while the Teredo adapter was in the qualified state, it wasn’t used to pass any traffic between the DirectAccess client and the DirectAccess server.

This put the user in a bit of a bind. However, Pat came up with a solution.

If you find yourself in this situation, what you need to do is disable the 6to4 adapter using the command:

netsh interface 6to4 set state disabled

This disables the 6to4 adapter and allows the DirectAccess traffic to be routed over the Teredo adapter. Yes, I know that you’ve heard me say that Teredo is used when the DirectAccess client is connected to the network from behind a NAT device, and that’s still true. But the reason why Teredo is used in NAT scenario is not because being located behind a NAT device is required by Teredo, it’s because the 6to4 adapter won’t come up when the DirectAccess client doesn’t have a public IP address, so Teredo is the next IPv6 transition technology “in line” to start.

While 6to4 has a little less protocol overhead compared to Teredo (because Teredo adds a IPv4 header and a UDP header while 6to4 only adds an IPv4 header) the performance difference is unlikely to be noticeable to your users. For this reason, you might want to consider setting up a secondary DirectAccess GPO that disables 6to4 on the DirectAccess clients. In this way you’ll be able to avoid this problem completely and save both your users and the Help Desk from a potentially frustrating situation.

(Props to Pat Telford for providing the scenario and the solution).

This article was originally written by:

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder