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.
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:
In the first step of the example, the client tries to find the IP address of a server called x.contoso.com:
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.
After DNS64 gets the responses from the corporate DNS server it decides which address to return to the client:
In this example, x.contoso.com 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.
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.
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.
Senior Program Manager, UAG Product Group
" 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?
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.
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
Does the DNS64 need to talk on IPv6 to the Corporate DNS Server? or could it do it on IPv4?
Yes, DNS64 can communicate with IPv4 only DNS servers.
How does NAT64 know if the dst-address to which packet is sent is an IPv6 address or IPv6 address with embedded IPv4 addrs
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.
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.
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.
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?
If an ISATAP entry is not created in DNS, is it safe to assume that all requests will be resolved as NAT64 addresses?
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)
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?
How to i get this application???
i need it.
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.