Extending DirectAccess to IPv4 Servers

On its own, DirectAccess makes use of IPv6 to route traffic from a remote Windows 7 client over the Internet to the DirectAccess server that bridges the traffic to a protected intranet server. As IPv6 support is incomplete throughout the Internet, DirectAccess employs transition technologies such as 6to4 and Teredo to traverse the IPv4 Internet or NAT (Network Address Translation) networks. But if the intranet server doesn't support IPv6 with a dual-layer IP stack, DirectAccess can't complete the connection.

Forefront UAG 2010 solves this problem by implementing NAT64 and DNS64 at the network edge. When a remote client tries to access an intranet server, UAG sends two DNS (Domain Name System) lookups to the intranet DNS server-one for an IPv4 A record and one for an IPv6 AAAA record. If the DNS server has both records, it will return the AAAA record to UAG and standard DirectAccess communications will be employed. If for some reason an application on the server does not support IPv6 while the server itself does, administrators should disable the IPv6 support on the server or remove that server's AAAA record from DNS to avoid complications.

If only an A record gets returned, UAG assumes the server only uses IPv4 and NAT64 must be employed. NAT64 adds a prefix to the server's IPv4 address and returns the full value (prefix plus IPv4 address) to the requesting client. When the client begins communications with the server, UAG strips off the prefix and creates a new IPv4 packet to send to the server. When the server responds through the same UAG gateway, UAG recrafts the packet for IPv6 with the prefix and sends it to the client.

To test UAG's ability to deliver DirectAccess connectivity to legacy applications and servers, I added a Windows Server 2003-based member server running Exchange 2003 to my test network. Although Windows Server 2003 does support IPv6, it has a dual-stack IP implementation that doesn't work with DirectAccess.

Through UAG, my remote client was able to access Exchange as if the machine were connected directly to the intranet. I was able to connect to Outlook Web Access, and I was also able to connect to Exchange from Outlook without needing to change any settings on the client.

I also tested UAG's DirectAccess functionality with a non-Microsoft Web application, to see whether those worked properly as well. I added an old firewall appliance that doesn't support IPv6 to the intranet and added the appropriate A record to my DNS server. Again, from my remote client, I was able to successfully access the appliance's Web-based management console via UAG DirectAccess.

For my tests, I deployed UAG DirectAccess in an end-to-edge configuration, terminating encryption and authentication at the UAG server at the network edge. For companies looking to deploy encryption end-to-end-all the way from the remote client through to the intranet server-getting UAG DirectAccess to work with non-Microsoft servers will likely be more complicated. However, third-party software maker Centrify in February will introduce DirectSecure, which promises to extend end-to-end DirectAccess connectivity and security to Unix and Linux servers.

Microsoft also claims that UAG allows DirectAccess to work in Windows 2003-based domains, although I did not test this claim.