Today I would like to identify some of the acronyms and explain the different technologies at work “under the hood” of Microsoft UAG DirectAccess. One of the great things about the wizard-driven nature of configuration in DirectAccess is that you don’t necessarily need to know what is going on in the background, but most DA Admins will want to explore and understand the underlying technologies at some point. Why not today?
Let’s start with the client side of the connection. When a DirectAccess client computer connects to its DirectAccess gateway in the corporate network, it chooses one of three transition technologies to establish a tunnel. A transition tunnel is needed because DirectAccess packets are IPv6 packets, but most of the internet today is still IPv4. So each of the three client-side transition technologies – 6to4 | Teredo | IP-HTTPS – each work to accomplish the same goal: Encapsulate the IPv6 packets inside IPv4 headers so they can be transmitted over the internet.
The DirectAccess client computer attempts to establish a 6to4 tunnel first, but can only do so if the client’s NIC has been assigned an actual public IPv4 internet address. This is not a very common scenario, the most common situation where you might find yourself with a public IP address is when using a broadband card provided by a cellular carrier. I have seen some hotels issue public IPs to computers inside their network as well, though this is rare and I expect it will become increasingly rarer in the future. 6to4 uses IP Protocol 41 as its transport method, and occasionally cell carriers will block Protocol 41 on their networks which means 6to4 cannot function anyway. This potential problem that would result in a helpdesk call combined with the rareness of 6to4 being used in the first place leads me to recommend as a best practice disabling the 6to4 interface on all of the DA client computers via GPO. One other point to add to this is that if/when you move to a multi-site DirectAccess deployment (multiple DA gateways in different locations) you must disable 6to4 anyway.
Teredo is the most common connectivity method for DirectAccess clients. It attempts to connect whenever a DA computer is sitting behind a NAT. For example, when you are sitting at home and you have received a “192.168.something” address from your home router. One recommendation I always make during installations is to use a GPO (same GPO as the one that disables 6to4 perhaps) to set your Teredo State to “EnterpriseClient” on the client machines. By default Teredo runs in “Client” state and will not connect if the computer is sitting inside of a domain network. Sometimes users plug into clients or other business networks, or sometimes users have domains on their home networks, and setting Teredo to EnterpriseClient allows Teredo to connect when inside a domain network. Teredo does the same job as 6to4, encapsulates IPv6 packets inside IPv4 headers, but Teredo uses UDP port 3544 for its transport. Therefore, if you are sitting behind a port restricting firewall that doesn’t allow UDP…
This is the method of last resort for creating a transition tunnel for DirectAccess. IP-HTTPS takes the IPv6 packet, encapsulates it inside an IPv4 header, and then throws that inside an HTTP header that is encrypted, creating an SSL traffic stream. This enables DirectAccess traffic to make its way successfully through port restricted firewalls (even a firewall where only HTTPS traffic is allowed), but is the method of last resort because you are essentially encrypting every packet twice, once with the standard DirectAccess IPsec encryption and then again with the SSL encryption. So this is a less efficient protocol, which is really the only reason that it is not the one and only protocol.
The Intra-Site Automatic Tunnel Addressing Protocol is also an IPv6 transition technology, similar to the three mentioned above. Its job is also to encap IPv6 packets inside IPv4 headers, but the main difference is that ISATAP is for use INSIDE your corporate network. UAG contains a great feature – NAT64/DNS64 – that converts the IPv6 packet stream into IPv4 for application servers and networks that do not understand IPv6 (more on that later) but occasionally you may have the need to make an outbound initiation from the internal network out to a DirectAccess connected client machine. The most common example of this is a Helpdesk PC trying to RDP into a DirectAccess laptop. When you want to generate a true outbound initiation like this, when the Helpdesk personnel punches “CLIENT1” into the RDP client, their PC is going to ask DNS how to get to CLIENT1. DNS is going to respond with the IPv6 address that the DA computer is currently connected with, and then that Helpdesk computer has to have an IPv6 layer of connectivity to be able to establish that connection. If you have native IPv6 inside your network then great, you don’t need ISATAP. If you do not have native IPv6 inside as most companies do not, you can use ISATAP to create a “virtual IPv6 cloud” inside your network. Your UAG box will act as an ISATAP relay which you can think of as an IPv6 DHCP server. You configure your Helpdesk PC to point at the UAG server for its ISATAP configuration, and it gets assigned an ISATAP IPv6 address. Then when the RDP connection takes place, those packets stream over the ISATAP connection (which is taking the IPv6 packets and putting them in IPv4 headers so your internal network and routers don’t need to know anything about IPv6) and those packets can then make their way successfully outbound to the DirectAccess client machine.
Note: Neither native IPv6 or ISATAP are required for a successful UAG DirectAccess implementation. Many management functions like Group Policy updates and patches for the DA client computers are actually “pulls” not “pushes” and therefore the management servers inside the network don’t actually need outbound access to these client computers as they are simply responding to the “pull” request that was initiated by the client. Those pull responses will happen successfully without any form of IPv6 connectivity inside the office.
NAT64 / DNS64
These two technologies (pronounced “NAT 6 to 4” and “DNS 6 to 4”) are included with UAG and are the mechanisms used to make your IPv6 DirectAccess packets be able to successfully contact IPv4 application servers inside your network. When your Outlook requests “EXCHANGE01” the DA client will ask your UAG appliance how to contact EXCHANGE01. UAG in turn asks DNS. If DNS responds with a AAAA (IPv6) record, UAG passes that along to the client who is happy to simply use the IPv6 record for communications back and forth. However, if EXCHANGE01 is a Server 2003 that doesn’t know anything about IPv6, DNS is going to return a regular A record which the DirectAccess client computer doesn’t know what to do with. Therefore, when DNS64 in UAG realizes that it’s talking to an IPv4 host inside the network, it creates a “fake” IPv6 address on the fly and returns that address to the DA client instead. Then DNS64 and NAT64 combine to create a transport method between client and server, where the client always thinks it’s talking to an IPv6 server, and the server always thinks it’s talking to an IPv4 client. There is nothing to configure to make this work, it simply does. It’s a beautiful thing!
One thing I didn’t discuss is the actual encryption of the DirectAccess traffic. Of course an IP-HTTPS stream would be SSL encrypted, but you obviously wouldn’t want clear-text packets flowing through the internet inside a UDP tunnel when connected over Teredo! Therefore regardless of what transport method the client chooses to connect with (6to4, Teredo or IP-HTTPS) inside that transition tunnel are IPsec tunnels which are carrying the actual packets the client is sending and receiving. In a typical DirectAccess implementation there are two IPsec tunnels at work on every DirectAccess client. The first is called the “Infrastructure Tunnel” and is a tunnel that is automatically established based on computer account and certificate authentication. This first tunnel is restricted only to your management servers. Domain controllers so that the user can successfully authenticate and so that Group Policies can be pulled down, and then whatever other management servers inside your network that you might want to have access to the DirectAccess client computers prior to user authentication. Then once user authentication does happen, a second IPsec tunnel is established based on both computer certificate and user authentication and this second “Intranet Tunnel” carries all of the user driven traffic.
There are potentially many more acronyms that we could discuss here. Things like NLB, NAP, OTP, etc etc. Those items are a little bit more generic and though they do have specific tie-ins with DirectAccess, I think I’ll leave it at that for today. As always, please feel free to reach out to me directly if you have any questions.