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