DirectAccess, forced tunneling and world-wide IPv6 launch
IPv6 is here, at least in some places it is. With the World IPv6 Launch on June 6th 2012 many websites and networks are switching on IPv6. Websites such as www.bing.com, www.facebook.com, www.google.com and www.yahoo.com are all permanently available via IPv6 as well as IPv4.
While this should be an invisible change for most, IPv6 connectivity does rely on IPv6 transition technologies such as 6to4 and Teredo to send traffic over IPv4 networks when your client does not have a native IPv6 address. These are the same IPv6 technologies used with DirectAccess communications so you should be aware how this affects client connections.
When a client resolves an Internet name to an IPv6 address, the client will connect to that resource using the available native IPv6 or IPv6 transitional technology connection. By default, Windows 7 clients are configured to use public Microsoft 6to4 and Teredo relays for bridging traffic between the IPv4 and IPv6 Internet networks. When these same computers are provisioned as DirectAccess clients, the DirectAccess server is configured as the new relay. This means that traffic destined to the IPv6 Internet will relay through the DirectAccess server and this server must be properly configured for the external IPv6 connection.
DirectAccess Deployment Guide - Connect to the IPv6 Internet
This should not be an issue with a standard DirectAccess server implementation but may be an issue in some deployments utilizing the ForceTunnel optional functionality. DirectAccess ForceTunnel clients utilize the IPHTTPS IPv6 transitional technology which encapsulates IPv6 packets within a TLS tunnel. The IPHTTPS communication requires only TCP 443 traffic between the DirectAccess client and server so some organizations have external packet filtering policies to only allow this specific communication. In order for these clients to relay IPv6 traffic through the DirectAccess server to the IPv6 Internet additional policies must be in place to allow the 6to4 communication from the DirectAccess server to the upstream defined external 6to4 relay which requires protocol 41 inbound and outbound.
DirectAccess Deployment Guide - Packet filtering for the Internet firewall
All ForceTunnel client name resolution is provided through the DirectAccess server via the Name Resolution Policy Table (NRPT) "." rule. If the DirectAccess server is able to resolve an external resource DNS name to an IPv6 address then this response will be sent directly back to the DirectAccess client.
The client will forward the traffic through the DirectAccess server which must have the ability to connect to native IPv6 Internet via the default external 6to4 relay. This requires Protocol 41 to be allowed outbound from DirectAccess server (which is not normally required for IPHTTPS ForceTunnel client connections).
If the DirectAccess server cannot access a particular IPv6 address location then the DirectAccess client cannot either. The DirectAccess server will use 6to4 or native IPv6 for external connectivity since Teredo is configured as a server connection, not as a client.
With the UAG DirectAccess NAT64/DNS64 IPv4 to IPv6 protocol transitioning you may have a couple of options exist to work-around this issue for connectivity to these public IPv6 resources if external IPv6 connectivity cannot immediately be enabled for your infrastructure.
1. You can ensure that the UAG DirectAccess server only resolves public DNS names to IPv4 address. In this case the Force Tunnel clients will continue to use NAT64 to communicate with the external websites via IPv4.
2. Reconfigure the UAG DirectAccess Force Tunnel connections to use the web proxy option. If the web proxy server can access the external website then the client connection will succeed.
Blog post written by Billy Price