Extending DirectAccess to IPv4 Servers
Microsoft Forefront UAG 2010 Makes DirectAccess Feasible
Microsoft's Forefront Unified Access Gateway 2010 addresses many of the shortcomings of the company's new always-on remote connectivity solution, DirectAccess, providing sorely needed measures of performance and availability scaling, global management, and backward compatibility to help move DirectAccess beyond mere pilot projects to actual deployment on real networks.
While Forefront UAG 2010 has its own shortcomings and limitations, an ecosystem of products and vendors is appearing around DirectAccess to further extend its functionality and reach.
When I tested DirectAccess in October 2009, I found that DirectAccess (which is baked into Windows 7 Enterprise and Ultimate on the client side as well as Windows Server 2008 R2) made for an interesting and effective pilot project. However, its lack of scale, global manageability and backward OS compatibility on both the client and server sides would effectively limit its usefulness on most live domains and networks.
Into the breach steps UAG, which addresses each of those concerns. Administrators who install UAG on each DirectAccess server in the network (thereby creating UAG DirectAccess servers) can scale DirectAccess management and performance beyond a single server by creating an array to aggregate all the servers. UAG's NAT64 and DNS64 implementations provide DirectAccess connectivity to IPv4-only intranet servers and applications, while SSL (Secure Sockets Layer) VPN functionality provides access to remote clients using older operating systems or to those not joined to the domain.
For the purposes of this test, however, I concentrated specifically on the enhancements to DirectAccess that UAG affords, and therefore did not look at UAG's SSL VPN implementation.
Forefront UAG 2010, which started shipping in December, is licensed through Microsoft's volume licensing program and requires both per-server licenses and CALs (Client Access Licenses). Each Forefront UAG server license costs $6,341 (which does not include the license cost for the underlying Windows Server 2008 R2 OS), while CALs (which can be purchased per user or per device) are $15 each. Large customers ordering over 10,000 access licenses are eligible for a volume discount.
Corporate buyers should note, however, that Microsoft has announced plans to add the UAG CAL to the Enterprise CAL Suite sometime in the first half of 2010, so the UAG client licenses may be available without additional charge to those with up-to-date Software Assurance coverage at that time.
Microsoft's Website also lists several hardware partners that may soon be shipping turnkey appliances running Forefront UAG 2010, although nAppliance Networks appears to be the only partner presently offering such an appliance.
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.
Forefront UAG 2010 also allows enterprise administrators to scale both the management and performance of DirectAccess. Whereas DirectAccess by itself requires administrators to individually configure each DirectAccess server, UAG allows administrators to define one UAG DirectAccess server as an array master. This effectively replaces the DirectAccess management snap-in with a UAG snap-in, through which a policy created on the master will be automatically replicated to all member servers in the array.
When I added a second UAG server to my network, I decided to use Windows' built-in Network Load Balancing technology. This required that I define virtual IP addresses (one on the intranet and two on the Internet) to represent the cluster. I had to create a certificate for the VIP, and ensure that a certificate was exported to the store on each UAG server in the array.
I also needed to patch each UAG server with KB977342, as ISATAP and 6to4 tunneling do not work properly on Windows Server 2008 R2 when Network Load Balancing is enabled.
With two servers in my UAG array, from my remote client I initiated a connection to my Exchange server on the Intranet. By looking at certificate information on the client, I was able to determine which UAG server in the array was parsing the connection. I then paused that UAG server's virtual machine, simulating a server failure.
After about a minute, the connection failed over to the second UAG server in the array, re-establishing the connection between remote client and the Exchange server. The delay is due to a 60-second wait period before Windows will break an IP Security association. This delay is put in place to avoid excessive IPSec negotiations with clients on lossy network connections, but in this case the wait period can mean a minute-long lack of remote connectivity that could lead to some support calls.
Although the IPSec timeout is not configurable, Microsoft officials have said there are programmatic workarounds that can be done on the client end to break the connection. If this timeout becomes an issue for customers, they said, Microsoft will look into providing a fix to do that.
Network administrators who don't want to rely on Windows' built-in load balancing capabilities can instead turn to Microsoft partners for an external solution allowing them to balance traffic among multiple UAG gateways. In January, F5 Networks announced its Application Ready Solution for Microsoft Forefront UAG 2010, a set of configurations designed to get the F5 Big-IP Local Traffic Manager (Version 9.4 or higher) to balance UAG-supported protocols such as HTTPS (HTTP Secure), IPSec or Teredo.
How I tested
I installed most of the nodes that made up my test network on VMs within Hyper-V, installing separate instances of Windows Server 2008 R2 Enterprise for the domain controller (1GB RAM), the application/location server (1GB RAM), the Internet DNS server (1GB RAM) and both DirectAccess/Forefront UAG 2010 servers (2GB RAM each), plus a Windows Server 2003 Enterprise server running Exchange 2003 Service Pack 3 (2GB RAM). All of these systems were installed on a single Lenovo ThinkServer RD210 running Windows Server 2008 R2 Standard with the Hyper-V role enabled. The physical server was outfitted with a pair of Intel Xeon E5540 2.53GHz processors, 12GB of DDR3 (double data rate 3) 1333MHz RAM and four 146GB, 15K SAS drives in a RAID 10 configuration.
I installed the 32-bit Windows 7 Enterprise client on a Dell XPS M1330 laptop with 3GB of RAM.