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 (“” 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 “” is the domain suffix, 2002:c00a:a02::c00a:a02 is the DNS64 address and “” is the network location server:


In the first step of the example, the client tries to find the IP address of a server called


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.


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, is an IPv4 only server that needs NAT64 to bridge all traffic:


UAG screen where the NAT64 prefix is configures:


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.


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.








Meir Mendelovich

Senior Program Manager, UAG Product Group

Comments (18)
  1. MeirM [MSFT] says:

    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 :->

  2. thomas w shinder - msft says:

    Hi Arun,

    If you don't use the UAG DNS64 service, the server won't have a mapping for your IPv4 hosts on the intranet, and won't be able to create the NAT64 address for the intranet host. You would never use an external DNS server to resolve internal host names in a DirectAccess scenario.



  3. MeirM [MSFT] says:

    Yes, DNS64 can communicate with IPv4 only DNS servers.

    Meir :->

  4. thomas w shinder - msft says:

    Hi Arun,

    NAT64 works with DNS64. When the client sends a name query request, the DNS64 (which is a DNS proxy) services fowards the query to the DNS server. If the DNS server returns an IPv6 address (such as an ISATAP address) it will forward the IPv6 address to the DirectAccess client; if an IPv4 address were returned, the NAT64 service would convert the IPv4 address to an IPv6 address and return that to the DirectAccess client. The DirectAccess client then sends a request to that address, The NAT64 services on the UAG DirectAccess server sees the request to that IPv6 address and is aware that this address is mapped to an IPv4 address – it then NATs this to the IPv4 address forwards the connection to the IPv4 address of the destination host.



  5. Dave Ryan says:

    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?

  6. Bill Hobson says:

    " 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?

  7. Ben [MSFT] says:

    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

  8. stef says:

    Does the DNS64 need to talk on IPv6 to the Corporate DNS Server? or could it do it on IPv4?

  9. arun says:

    How does NAT64 know if the dst-address to which packet is sent is an IPv6 address or IPv6 address with embedded IPv4 addrs

  10. arun says:

    Thanx Tom.

    The DNS query from the client can be sent to any server. The client can be configured to used publicly available DNS servers instead of the DirectAccess DNS64.

    In such case, the pre-defined prefix may be different and NAT64 will see an an IPv6 packet from which it is not able to identify if the IPv6 contains a mapped IPv4 address.

    How do we handle such a case.

  11. PatRick says:

    Thanks Tom!

    Does NAT64/DNS64 on UAG perform any caching?  We did a DR test recently where an IPv4 address had to be changed (It points to a non-IPv6 load balancer, so no AAAA record).  Even though an NSLookup instantly  replied with the correct IPv4 address, it seemed to take a while before DA started sending traffic to the new IPv4 address.

    If it does cache the IPv4 address, is there a way to configure the TTL, or manually flush the cache?

  12. Mario says:

    If an ISATAP entry is not created in DNS, is it safe to assume that all requests will be resolved as NAT64 addresses?

  13. Boudewijn says:

    With DA hosted by UAG. Are you not able to ping or reach and IPv4 IP Address directly?

    (with this question I mean that you don't use a DNS name)

  14. yahya says:

    To All.

    How to i get this application???

    i need it.

  15. Westar says:

    If the IPV4 address is in DMZ, is there any special configurations needed to access this website using DirectAccess? I am able to access internal website successfully.

  16. Bharat says:

    Do we need to Download/install forefront UAG for implementing NAT64 / DNS64 ?

  17. Vali basha says:

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

  18. Macelsters says:

    I am trying to implement DirectAccess on a Server 2012r2 server and am running into problems with my windows 7 clients that are connected to the intranet. I am having trouble getting assistance on this through regular channels. I followed the guidelines
    for configuring DA with the following considerations: Single NIC behind edge device, no IPv6 implemented on intranet and compatibility for Windows 7 clients enabled.

    I’ve managed to get the windows 7 clients connecting, establishing the IPSec SA and working properly when connected from outside the intranet, but when they are connected to the intranet they cannot communicate with DNS. I looked at the dnsclient state and
    noted that they are correctly detecting that they are on the intranet. It is my understanding that they should then disable any NRPT policies and use DNS as assigned on their NICs having detected an intranet connection, but this is not the case – they still
    attempt to pass DNS requests to the IPv6 address of the DA (DNS64) server and are timing out, probably because they do not have an IPSec SA established since they’re not supposed to be tunneling while on the intranet. Can I get some assistance with this? I
    feel like I’m SOO close…

Comments are closed.

Skip to main content