Deep Dive Into DirectAccess - Part 2

Hi,

My name is Ben Bernstein and I’m a Program Manager for the Forefront Unified Access Gateway (UAG) team.

This is a follow up blog post to the blog post I recently made.

“Do Do Do DA DA DA is all I want to say to you” (Gordon Sumner)

I hope you are intrigued by DirectAccess (DA). Today I’m going share with you some thoughts about the value Forefront Unified Access Gateway DirectAccess adds to the Windows 2008 R2 DirectAccess offer.

“If you can’t change the world. change yourself. And if you can’t change yourself....change the world” (Matt Johnson)

You can think of UAG as “glue”, not just for the DirectAccess scenario, but for many other scenarios. UAG in my eyes is a vehicle for delivering new identity and access related technologies.

Let’s go back to the way UAG incorporated DirectAccess technology and specifically how it added to it the ability on the UAG DirectAccess server to connect to IPv4-based resources.

As you might have read in my previous post, DirectAccess is based on IPv6 technology. While this enables some cool features in regards to how clients tunnel their way to the UAG gateway, it poses a challenge since most organizations today don’t have an IPv6 ready intranet.

To make the Windows DirectAccess technology support IPv4 based servers, UAG implements a technology called NAT64/DNS64.

NAT64 (pronounced “NAT six to four”) is a component that is broadly based on the IETF memo. It enables initiating communication from an IPv6 based network to an IPv4 based network. In many ways I think of it as a subset of the NAT-PT capabilities that are relevant to the DirectAccess scenario.

For NAT64 to work it needs to utilize another component called DNS64 which is also based on the IETF memo. DNS64 is a DNS server on the UAG server which “multiplexes” DirectAccess clients DNS requests for IPv6 records into two DNS requests, one for IPv4 records and one for IPv6 records. If IPv6 DNS records exist they are sent back to the client. If there are none, then IPv4 records are translated into “fake” IPv6 records - owned by the NAT64 device. When a DirectAccess client tries to access them, it actually uses NAT64 addresses.

If you are wondering how the client queries the DNS64 instead of its regular DNS server, it is quite simple. Like all other client configurations, that configuration is also set using group policy. Group policy tweaks the Name Resolution Policy Table (NRPT) settings. NRPT settings tell the client to send DNS requests with a specific DNS suffix to a given DNS server. Type “netsh name show policy” on the client to see what NRPT settings exist.

“One is the loneliest number that you’ll ever do” (Aimee Mann)

One is definitely a lonely number, especially as a point of failure. What I mean is that once you have DirectAccess working, you probably want to examine two important aspects of deploying any service: scalability and fault tolerance. UAG in general and UAG DirectAccess solution specifically supports having both of these by utilizing Windows Network Load Balancing (NLB) technology. The great thing about this technology is that it doesn’t require additional hardware. You just decide the number of servers you want to use, and that is it. The way to deploy multiple servers in UAG is to create an array of UAG machines. In the DirectAccess scenario, you create such an array and then turn on UAG’s NLB to add scalability to DirectAccess and to make it fault tolerant.
An interesting side note is that we needed to tweak Windows NLB a little for it to work with UAG DirectAccess. The IPsec state of a client, needs to stay on a single machine and that meant that all traffic to and from a specific client needs to stick to a specific UAG array member. So we created some tweaks so that traffic initiated from and to corporate resources by the DirectAccess clients, stick to the UAG array member which “owns” the client (this challenge is sometimes referred to as “bi-directional affinity”). The component that enables this functionality is a UAG driver called “Microsoft Forefront UAG DirectAccess NLB Helper” and nicknamed “daeng”

I’ve seen the end of the day come too soon … Rest a day, for tomorrow you can’t tell… (Beck Hansen)

The bottom line is that these three mechanisms (DNS64, NAT64, and the NLB driver) enable UAG to utilize DirectAccess technology more fully, and enable a smoother deployment of the DirectAccess technology…

See you next time

Ben