Deep Dive Into DirectAccess – NAT64 and DNS64 In Action

In the previous posts my colleague Ben provided an overview of Forefront UAG DirectAccess and its NAT64 and how it is different from NAT-PT. In this post I will show a step-by-step example of how UAG DirectAccess NAT64 and DNS64 work together to provide DirectAccess users access to IPv4 machines on the corporate network.

Step 1: Client DNS query

It all starts when the DirectAccess client sends a DNS query to the UAG DNS64 to get the address of an application server. It is important to note that DirectAccess clients have connectivity to the corporate network only over IPv6, therefore their DNS queries are always IPv6 DNS queries that are called “AAAA” (quad A). For more details on DNS resolution with IPv6 see here.

All clients’ DNS queries for corporate destinations are assigned to UAG DNS64 because UAG alters the clients’ Name Resolution Policy Table (NRPT) via its group policy. For more explanation on how NRPT works, see here. The NRPT table is configured with the list of corporate domains (“contoso.com” in the example below) and the DNS associated with them. It is configured in the DNS suffixes page in the UAG DirectAccess infrastructure servers wizard.

In our examples “contoso.com” is the domain suffix, 2002:c00a:a02::c00a:a02 is the DNS64 address and “inout.contoso.com” is the network location server:

clip_image002

In the first step of the example, the client tries to find the IP address of a server called x.contoso.com:

image

Step 2: DNS64 query

After it got the query from the client the UAG DNS64 sends two DNS queries: an IPv4 query (A query) and an IPv6 query (AAAA query) to the corporate DNS. UAG locates the corporate DNS servers based on its own DNS configuration.

image

Step 3: DNS Response

After DNS64 gets the responses from the corporate DNS server it decides which address to return to the client:

  • If DNS64 got in the response an IPv6 address (AAAA Response) then the application server has IPv6 connectivity so DNS64 returns this address to the client. Please note that there are cases where the DNS64 will get both IPv4 and IPv6 address. In these cases, it will return the IPv6 address.
  • If DNS64 got in response only an IPv4 address it is assumed that there is only IPv4 connectivity to this server and therefore NAT64 will have to bridge all traffic. Since the client needs an IPv6 address DNS64 generates an IPv6 address from the IPv4 address based on the NAT64 prefix configured on the UAG DirectAccess prefixes page.

In this example, x.contoso.com is an IPv4 only server that needs NAT64 to bridge all traffic:

image

UAG screen where the NAT64 prefix is configures:

image

Tip: If there is a server that has IPv6 connectivity but its applications do not support IPv6 and therefore it needs NAT64 to bridge all the traffic, you could either disable its IPv6 interfaces or prevent the DNS from returning its IPv6 address from the corporate DNS.

Step 4: Client sends packets to server

Now after the client machine has the address of the application server, it starts sending data packets to this server. The packets are sent to the UAG DirectAccess NAT64 since all IPv6 addresses that are included in the NAT64 prefix are routed to UAG DirectAccess.

image

Step 5: NAT64 forwards the packet using IPv4

NAT64 receives the data package and tries to determine the IPv4 address that is associated with the destination IPv6 address. Then it creates a new IPv4 packet that has the same payload and sends it to the application server.

For the application server, the origin of the IPv4 data packet is the UAG server. If UAG DirectAccess is deployed in high availability and scalability mode on an array with integrated Windows Network Load Balancing (NLB), the packet’s origin would be the internal device IPv4 address of the node that handled the traffic. In that case, when the application server replies to this packet, it will reach the node that interacts with the client.

image

 

 

 

 

 

 

Meir Mendelovich

Senior Program Manager, UAG Product Group

Comments

  • Anonymous
    January 01, 2003
    Hi Bob, This is exacyly what we are trying to solve with UAG NAT64/DNS64 where we make the IPv4 machines on the internal network available to DirectAccess clients. Meir :->

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Could an NT service using IPv4 on the DirectAccess Client be able to talk to a IPv4 application on the domain or would the application have to be re-written in IPv6?

  • Anonymous
    November 13, 2009
    " It is important to note that DirectAccess clients have connectivity to the corporate network only over IPv6" This seems to indicate that if the client isn't on an IPv6 network, then it won't work. Is that true?

  • Anonymous
    November 15, 2009
    Hi Bill, The client would have connectivity over IPv6 network even when in IPv4 environment as it would use Teredo,IP-HTTPs, or 6to4 to enable the client to connect over IPv4 network using IPv6

  • Anonymous
    November 18, 2009
    The comment has been removed

  • Anonymous
    January 05, 2011
    How does NAT64 know if the dst-address to which packet is sent is an IPv6 address or IPv6 address with embedded IPv4 addrs

  • Anonymous
    March 02, 2011
    The comment has been removed

  • Anonymous
    August 22, 2011
    The comment has been removed

  • Anonymous
    October 19, 2011
    The comment has been removed

  • Anonymous
    February 17, 2012
    The comment has been removed

  • Anonymous
    March 09, 2012
    To All. How to i get this application??? i need it.

  • Anonymous
    December 26, 2012
    The comment has been removed

  • Anonymous
    November 12, 2014
    Do we need to Download/install forefront UAG for implementing NAT64 / DNS64 ?

  • Anonymous
    April 20, 2015
    Hi Thomas, I am getting NAT64 unhealthy warning,below is the screen shot. Could you able to help me please.

  • Anonymous
    May 31, 2015
    The comment has been removed