A Complete Guide to UAG DirectAccess (Part 3) – NAT64/DNS64

By /

If you would like to read the other parts in this article series please go to:

Introduction

In part 1 of this series of articles that comprise the Complete Guide to UAG DirectAccess, we talked about the definition of DirectAccess and provided a high level explanation of how DirectAccess works. In part 2, we went over the details of the IPv6 transition technologies that enable the DirectAccess client and server to communicate with each other over IPv4 intranets and the IPv4 Internet. In that article, we also talked about how the DirectAccess client uses the Name Resolution Policy Table (NRPT) to determine which names should be resolved by internal DNS servers and which names should be resolved by Internet DNS servers.

That brings us to the current article, which is part 3 of the series. In this article we’ll talk about a key piece of technology that allows you to deploy DirectAccess today and not worry about upgrading your network infrastructure to IPv6 to support the IPv6 communications used by the DirectAccess client. This is important because most networks you encounter today are likely a mix of IPv4 only and IPv6 capable clients and servers. There are likely more IPv4 resources on your network than IPv6 capable resources. Given that this is the current networking environment for most companies, UAG DirectAccess needs a way to allow access to IPv4 resources on your network, because without this kind of support, very few production networks today would benefit from deploying DirectAccess.

The Solution: NAT64/DNS64

UAG DirectAccess handles the problem by implementing a couple of technologies that are not available with the Windows DirectAccess solution. These are:

  • NAT64 (pronounced NAT six to four)

  • DNS64 (pronounced DNS six to four)

These two technologies enable DirectAccess clients, which always “speak” IPv6 to the UAG DirectAccess server to connect to IPv4 only resources on the intranet.

When a DirectAccess client sends a request for resources using a single label name or a fully qualified domain name (FQDN), it first consults the Name Resolution Policy Table (NRPT). If there is a match on the NRPT and there is no exception rule for the name, then the DirectAccess client sends the name resolution request to the IPv6 (6to4) address of the UAG DirectAccess server. If the request is for a single-label name, then the DirectAccess client’s DNS client component will append DNS suffixes as configured on the NIC or through Group Policy.

When the UAG DirectAccess server receives this request, it sends the request to the DNS servers configured on its internal interface, in the order in which the DNS servers are listed. The DNS query request will be for both IPv4 Host (A) and IPv6 Quad A (AAAA) records. If the DNS server responds to the UAG DirectAccess server with a Quad A record, it will return this to the DirectAccess client and the DirectAccess client will connect to the IPv6 address included in the Quad A response over the DirectAccess IPsec tunnels.

However, if the DNS server responds to the UAG DirectAccess server with only an IPv4 Host (A) record, the DirectAccess client on the Internet is going to have a problem with this, since the DirectAccess client can only communicate over IPv6. To solve this problem, the UAG DirectAccess server’s DNS64 component will map the name to an IPv6 address and then inform the UAG DirectAccess server’s NAT64 component of the mapping between the IPv6 address and the IPv4 address.

For example, suppose the DirectAccess client on the Internet needs to connect to SRV1.contoso.com. It sends the name query request to the IPv6 (6to4) address of the UAG DirectAccess server over the IPsec tunnel. The UAG DirectAccess server sends an IPv4 Host (A)and an IPv6 Host (Quad A) request for SRV1.contoso.com to the DNS servers configured on its internal interface. The DNS server returns only an A record with the IP address 10.0.0.66. The DNS64 component on the UAG DirectAccess server maps 10.0.0.66 to an IPv6 address, such as 2002::0066 (this is for example purposes only, this would not be the address actually mapped to this server). The UAG DirectAccess server’s DNS64 component informs that NAT64 component that it should forward any incoming requests for 2002::0066 to IP address 10.0.0.66. Session state is also tracked so that responses from 10.0.0.66 are forwarded to the DirectAccess client. The UAG DirectAccess server forwards the name resolution response for SRV1.contoso.com with the IP address of 2002::0066 to the DirectAccess client on the Internet and the DirectAccess client sends a connection request to that address.

As you can see, DNS64/NAT64 acts as an IPv6/IPv4 protocol translator, so that the DirectAccess client on the Internet is able to connect to IPv4 only resources on the intranet. In practice, this means that the client side components installed on the DirectAccess client need to be IPv6 aware, but the server side components do not need to be IPv6 aware. This expands the number of scenarios in which DirectAccess clients can connect to intranet resources enormously.

Limitations

Unfortunately, as with all NAT-based solutions, there are some limitations and drawbacks to this solution. The primary limitations are:

  • NAT64/DNS64 will consume memory and processing resources and thus can have a negative performance impact on the UAG DirectAccess server.

  • NAT64/DNS64 works in a “forward NAT” scenario only. This means that you cannot “reverse NAT” from the intranet to the DirectAccess client from an IPv4 management station. The result is that you will not be able to initiate a connection from an IPv4 only management station to the DirectAccess client. However, the DirectAccess client is able to connect to the management station as long as the DirectAccess client initiates the connection. If your solution can leverage this existing connection, you will be able to connect back to the DirectAccess client.

  • NAT64/DNS64 doesn’t include any “NAT editors”. NAT editors are often used to allow applications that imbed networking information in their application protocols. For example, the FTP protocol embeds IP addressing information in its protocol and the OCS client imbeds an IPv4 address in its application protocol. These will not work with NAT64/DNS64 because there is no NAT editor to make them work correctly.

Those are the primary issues that you might run into when using the UAG DirectAccess server’s NAT64/DNS64 solution. Keep in mind that NAT64/DNS64 will only be used if the server on which your server application runs doesn’t support IPv6 or if the application itself doesn’t support IPv6. If the server and application both support IPv6, then NAT64/DNS64 won’t be used and the communication from the DirectAccess client to the destination server will be to the ISATAP address assigned to the server on the corporate network.

Note:
An interesting fact about UAG DirectAccess NAT64/DNS64 is that the NAT64 component is part of the TMG application installed on the UAG DirectAccess server, whereas the DNS64 component is part of the UAG code.

Another thing you should be aware of is that NAT64/DNS64 makes it possible to deploy DirectAccess in your organization without requiring Windows 2008 R2 anywhere except on the UAG DirectAccess servers. Your entire company can be running Windows Server 2003 domains, and resources can be hosted on Windows 2000 Server, or Windows Server 2003 or Windows Server 2008 or even non-Microsoft operating systems and the DirectAccess clients will be still able to connect to those resources. This is why NAT64/DNS64 is so important – because it enables you to deploy DirectAccess today, without the effort and expense of upgrading your infrastructure. If you have heard that you need an IPv6 network before you can deploy DirectAccess, now you know that is definitely not true; your network can be all IPv4 and still take advantage of the enormous benefits you get by deploying UAG DirectAccess.

Summary

In this article, you learned about how the DirectAccess client always uses IPv6 to communicate with the DirectAccess server. Because of this, we need a way to enable the DirectAccess client to communicate with resources on the intranet that are not yet IPv6 capable. You found out that the solution to this problem is the UAG NAT64/DNS64 service. This service is able to map names and addresses of IPv4 only resources to  IPv6 addresses that can be consumed by the DirectAccess client. This enables the DirectAccess client to initiate connections to resources on the intranet. However, there are some limitations to the NAT64/DNS64 service, such as the inability of resources on the intranet to initiate connections to the DirectAccess clients. Luckily, since in the majority of cases connections by management agents are initiated on the client side, there is probably not going to be much of a problem.

Coming up next

In this next part of this series (Part 4), we’ll talk about the key support infrastructure components that are required to get a UAG DirectAccess deploying working. Those components include:

  • Active Directory Domain Services and Group Policy

  • Domain Name Services (DNS)

  • A Public Key Infrastructure (PKI) and Windows Active Directory Certificate Services

  • Network Location Servers

  • Certificate Revocation List (CRL) servers

  • Windows Firewall with Advanced Security and Network Firewalls

  • Remote Access VPN servers

  • NAP and Smart Card Infrastructure

See you then! –Deb.

If you would like to read the other parts in this article series please go to:

About The Author

Debra Littlejohn Shinder is a technology and security analyst and author specializing in identity, security and cybercrime, utilizing her past experience as a police officer and police academy/criminal justice instructor. She has written numerous books and articles for web and print publications and has been awarded the Microsoft MVP designation for fourteen years in a row.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top