If you would like to read the other parts in this article series please go to:
- A Complete Guide to UAG DirectAccess (Part 1)
- A Complete Guide to UAG DirectAccess (Part 3) – NAT64/DNS64
- A Complete Guide to UAG DirectAccess (Part 4) – Infrastructure Requirements
- A Complete Guide to UAG DirectAccess (Part 5) – Infrastructure Requirements (Cont.)
IPv6 Transition Technologies
Because the DirectAccess client uses IPv6 to connect to the DirectAccess server and possibly to the servers on the corpnet, there must be a method you can use to allow these IPv6 messages to move over an IPv4 Internet and intranets. DirectAccess solves these problems by using a number of different IPv6 transition technologies that allow IPv6 messages to be tunneled in IPv4 headers so that they can move over today’s IPv4-only Internet and intranets. These are:
- The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
ISATAP is used on intranets so that ISATAP capable hosts can use IPv6 to communicate with one another. They do this by instantiating an ISATAP tunnel adapter which has an IPv6 address bound to it, and then wrap these ISATAP communications inside an IPv4 header so that they can be sent over the intranet routing infrastructure. When the communication reaches its destination server, the IPv4 header is removed and the IPv6 header and payload are exposed. ISATAP allows you to take full advantage of IPv6 communications without requiring you to upgrade your network gear and routing infrastructure to support IPv6. - The 6to4 Protocol
The 6to4 protocol is used by the DirectAccess client when the DirectAccess client is assigned a public IP address. As with ISATAP, a 6to4 tunnel adapter is automatically configured on the DirectAccess client, which has an IPv6 address bound to it. The DirectAccess client IPv6 communications are sent out this adapter and then encapsulated with an IPv4 header so that they can traverse the IPv4-only Internet to the DirectAccess server. The UAG DirectAccess Wizard automatically configures the UAG DirectAccess server as a 6to4 router for your organization. You don’t need to know anything about 6to4 if you don’t want to. 6to4 requires that all interposed devices between the DirectAccess client and server allow IP protocol 41 inbound and outbound. - The Teredo Protocol
The Teredo protocol is another IPv6 transition technology that the DirectAccess client can use to connect to the UAG DirectAccess server over an IPv4 Internet. Teredo is used when the DirectAccess client is assigned a private IP address, but has outbound access to UDP port 3544 on the UAG DirectAccess server. With Teredo, the IPv6 communications are sent through the Teredo adapter that is automatically configured on the DirectAccess client, and then they are encapsulated with an IPv6 header, which is then encapsulated with a UDP header. Teredo is the reason that two public IP addresses must be assigned to the external interface of the UAG DirectAccess server; these are used to determine which type of NAT device the DirectAccess client is located behind. In addition, all devices need to enable ping to enable the Teredo client to connect to them. - The IP-HTTPS Protocol
IP-HTTPS is an entirely new protocol developed by Microsoft to allow DirectAccess clients to connect to the UAG DirectAccess server when only outbound TCP port 443 is allowed to the client. You’ll use this when there are very restrictive firewalls set up or when the organization in which the DirectAccess client is located allows outbound access only through a Web proxy device. With IP-HTTPS, the DirectAccess client starts up an IP-HTTPS tunnel adapter and sends its messages over that. The messages are then encapsulated in an IPv4 header, when are then encapsulated in an HTTP header which is then encrypted using SSL (TLS) encryption. As you can imagine, there is significantly higher protocol overhead and higher processing overhead (due to the IPsec encryption and the HTTPS encryption), so performance for the IP-HTTPS connection is likely to suffer. Even if you use modern server processors (such as the Intel 5300 series which includes AES-NI technology on the chip) that can offload much of the encryption processing, you still have to deal with the protocol overhead. This means it ends up taking more packets to send the same amount of data. In addition, when the DirectAccess client is located behind a web proxy server, the web proxy server cannot require authentication for outbound access because the DirectAccess client doesn’t have a provision for entering authentication information that can be used by the web proxy server. Also, your users will need to configure the IP-HTTPS to use the web proxy server by initiating a netsh command so that the IP-HTTPS client knows which web proxy server to use.
It should be clear at this point that you want to avoid the IP-HTTPS configuration if you can. The DirectAccess client, when assigned a private IP address, will try to use Teredo, which provides reasonably good performance. Only when Teredo isn’t available will the DirectAccess client fall back to using IP-HTTPS.
While it seems at first glance as if all these IPv6 transition technologies are a lot to understand and remember, it’s important to note that the UAG DirectAccess Wizard does all the work for you. It configures the UAG DirectAccess server as a 6to4 router and a Teredo relay and router and an IP-HTTPS gateway. You don’t need to have a deep (or even moderate) understanding of these protocols to get DirectAccess working; all this IPv6 technology works under the hood to allow seamless and transparent connectivity for your DirectAccess clients.
In work we’ve done with a number of enterprise IT departments who are deploying DirectAccess to 1000 or more clients, the distribution of DirectAccess client connections appears to be around 70% Teredo, 25% IP-HTTPS and 5% 6to4. However, this distribution might change depending on how popular the requirement for disabling split tunneling ends up to be.
Figure 1
By default, the DirectAccess client uses split tunneling to allow users to access the Internet directly without forcing the connections to use the intranet gateways to access the Internet. This is commonly referred to as “split tunneling”. Your organization might have a policy against using split tunneling for its remote access VPN client connections and therefore might be concerned about this default configuration. You do have the option of using DirectAccess “Force Tunneling”, which disables split tunneling for DirectAccess client connections and forces the DirectAccess client to use an Internet gateway on your corpnet to reach the Internet. The downside of the Force Tunneling option is that the DirectAccess client must use IP-HTTPS, which can lead to performance penalties. Force Tunneling and split tunneling are discussed in more detail in the next section on the Name Resolution Policy Table (NRPT).
The Name Resolution Policy Table (NRPT)
The Name Resolution Policy Table (NRPT) is used by the DirectAccess client to determine which DNS servers it should use, depending on the domain name or FQDN of the destination to which it’s trying to connect. With the help of the NRPT, your DirectAccess clients will know to send DNS queries to the UAG DirectAccess server for name resolution when names within your intranet need to be resolved, and to send DNS queries for names outside your organization to the DNS server address configured on the DirectAccess client’s NIC.
For example, suppose your organization is comprised of many subdomains that lie under the contoso.com root domain. These domains can be in the same or different forests; in terms of name resolution it does not matter. When you configure the NRPT, you set it up with an entry that says that all requests for domains that match *.contoso.com should be sent to the IP address of the UAG DirectAccess server. The reason name resolution requests are sent to the IP address (the IPv6 address in this case) of the UAG DirectAccess server is that UAG takes the place of an intranet DNS server by installing its own DNS proxy. The DNS proxy on the UAG server will use the DNS servers configured on the UAG DirectAccess server’s internal interface to resolve the names requested by the DirectAccess clients.
What happens to names that aren’t included in the NRPT? In that case, the DirectAccess client sends name query requests to the DNS server address that’s configured on its NIC. When the DirectAccess client connects to the network, regardless of whether it’s behind a NAT device or assigned a public address, it will receive from the DHCP a DNS server address. It’s this address that the DirectAccess client will use to resolve all names that aren’t part of your organization’s namespace.
This type of DNS routing or conditional DNS forwarding gives rise to the default DirectAccess client configuration which enables split tunneling. The reason that we choose to make split tunneling the default configuration is because it significantly improves performance for the DirectAccess client and for hosts on the corpnet when they need to connect to Internet resources. If split tunneling were disabled (which is called “Force Tunneling” in DirectAccess parlance), all traffic would move through the IPsec tunnels; that includes both traffic destined for the corpnet and traffic destined for the Internet.
Some of you might be concerned about split tunneling because you’ve been told that split tunneling is “bad”. While that might have been true for VPN clients in the 1990s, modern Windows operating systems don’t enable attackers to route through VPN client to connect to the corpnet. The situation is even more secure with DirectAccess, because even if an attacker found some way to route connections from the Internet through the DirectAccess client, the connections would fail because IPsec enforces security on the tunnel based on the IP address of the DirectAccess client, in addition to the computer certificate, computer account, user account, and smart card requirements that are required to establish a connection. Since the security issues that lead to split tunneling do not and cannot apply to the DirectAccess client, there is no reason to consider split tunneling in a DirectAccess scenario to be a security problem.
I recently discussed the issue of split tunneling with a number of enterprises on an informal basis. Like most experienced network administrators, I also believed that split tunneling in general was not a good idea and believed that most enterprise administrators would not allow split tunneling for their VPN clients. I was surprised to find out that over 50% of the enterprises that we questioned regarding split tunneling stated that they now allow their VPN clients to split tunnel, both because the reasons for disabling split tunneling no longer apply and also because users became significantly more productive due to the performance enhancements. If your organization is still prohibiting split tunneling, you might want to review your current policies. In terms of DirectAccess and split tunneling, it’s also important to keep in mind that the issues that might have been related to VPN split tunneling do not apply to DirectAccess client/server connections.
The NRPT is also used to prevent the DirectAccess client from resolving specific names so that DNS queries for these names are never sent to the intranet DNS server (which in the case of UAG DirectAccess, is the DNS proxy on the UAG DirectAccess server). The most important example of this is the name of the Network Location Server (NLS). The DirectAccess client uses the NLS to determine whether it’s on the corpnet or not. If the DirectAccess client can connect to the NLS, it knows that it’s on the corpnet and turns off the NRPT. If the DirectAccess client cannot connect to the NLS, then it assumes that it is off the corpnet and leaves the NRPT enabled.
If the NRPT were configured so that the DirectAccess client could resolve the name of the NLS, the DirectAccess client on the Internet would think it was on the corpnet and turn off the NRPT. If the DirectAccess client on the Internet turns off the NRPT, it will not know to send DNS queries for corpnet names to the UAG DirectAccess server’s DNS proxy component and therefore would never be able to resolve intranet names. To solve this problem, the NRPT is configured with an exception rule to prevent the DirectAccess client on the Internet from resolving the name of the NLS.
For example, if the NRPT is configured to send all queries that match the string *.contoso.com to the DNS proxy on the UAG DirectAccess server, that would include a query for the name nls.contoso.com, which is the name of the NLS on the corporate network. But, if we create an exception for the name nls.contoso.com in the NRPT, even though the name nls.contoso.com matches the string *.contoso.com, the query will not be sent to the DNS proxy on the UAG DirectAccess server and instead will be sent to the DNS server configured on the UAG DirectAccess client’s NIC. Since it won’t be able to resolve this name, the DirectAccess client on the Internet will assume that it’s off the corpnet, and will leave the NRPT enabled.
Summary
In this article, part 2 of our Complete Guide to UAG DirectAccess series, we discussed the key IPv6 transition technologies that are used by the DirectAccess client and server to allow IPv6 messages to be moved over an IPv4 Internet or intranet. We also discussed the function and the value of the Name Resolution Policy Table, which DirectAccess uses to determine the DNS server to which it should send a particular name query request. In part 3 of this series, I’ll pick up with the NAT64/DNS64 capabilities included with the UAG DirectAccess server. See you then! –Deb.
If you would like to read the other parts in this article series please go to:
