DirectAccess clients are completly dependent on DNS to function, especially when you have IPv4 behind the UAG server. In these cases UAG acts as an ISATAP router which translates IPv6 into IPv4 as well as IPv4 into IPv6. To do this it uses some magic called NAT64 (“NAT six to four”) and DNS64 (“DNS six to four”). Here is a TechNet article on those two technologies, and here is a blog post with pretty pictures on how it works.
Essentailly, when an application tries to send traffic to a host name, the route it takes to reach that host name is determined by it’s DNS name. If the applications uses an IP address instead of a host name it’ll never use the DirectAccess virtual interfaces and instead route over the normal interface to the network immediatly available to the machine. The majority of applications will simply work over DirectAccess when they use hostnames to establish their connections, however there are some exceptions.
For example, when using ping.exe from a DirectAccess client, it can reach anything in the corpnet that’ll respond to a ping, however nslookup.exe will not return any results for those very same host names that you can ping. Why? Because nslookup does not use the Name Resolution Policy Table (NRPT) and by default uses IPv4. The request simply never traverses any of the DirectAccess interfaces to reach the corpnet in order to do the name lookup. You CAN use nslookup on a DirectAccess client to find addresses of machines behind a UAG server, but you must tell it to ask for an IPv6, and you must specify the IPv6 address of your DNS server. It’s a bit convoluted: nslookup -q=aaaa [hostname] [dnsipv6address]. For that reason, I generally avoid using nslookup as a part of any diagnostics with DirectAccess clients. Becides, if you try to ping a host name it’ll tell you what IP it’s using, be it IPv4 or IPv6.
Here are couple things you need to be aware of specifically related to DNS.
You should make sure you create an A-record in your external DNS that points to the first external IP address. Something like UAG.domain.com or DA.domain.com or DirectAccess.domain.com works pretty well but you can just as easily use the UAG server’s hostname. Keep in mind that no one will ever see or decidedly use this hostname, so it’s really pretty irrelevant what it is and there’s no need to make it “pretty” or user friendly. This name is just used by the DirectAccess client to bring up the IP-HTTPS interface. The name you use should be the same as the Common Name that you define when creating the IP-HTTPS certificate.
I mentioned earlier that DirectAccess clients can connect via one of three methods: 6TO4, Terreo and IP-HTTPS. To support IP-HTTPS connections DirectAccess encapsulates it’s traffic within HTTPS packets. This will require a web server certificate and therefore a hostname to register the certificate to. This certificate does not need to be issued from a third party certificate authority like VeriSign or Thawte or DigiCert because only your corporate domain members will be connecting to this HTTP service. So you can use a certificate issued from your own internal Enterprise CA since they will already be trusted by these domain member computers.
What does that have to do with External DNS you ask? The catch with using an internal CA for the IP-HTTPS certificate is that you will need to publish your CRL (Certificate Revocation List) to the internet so the certificate can be validated before bringing up the IP-HTTPS interface. That means you will need to create a DNS name where the CRL can be found and stand up a wen site to distribute the CRL. For those reason some people find it easier to use a 3rd party certificate. Tom Shinder has an article on how to publish your private CRL through UAG if you want to go that route.
Domain Name Services in a Windows Domain allows clients to dynamically update their DNS records. While this is pretty great, it also presents an opportunity for malicious users to try manipulating DNS records in an effort to divert trafic that is destined for a particular hostname to instead arrive someplace that it should not be going (aka “DNS Hijacking”). To mitigate some of this risk, the Windows Server DNS uses what’s called a “Global Query Block List” that prevents some of the more vulnerable protocols from being serviced by DNS requests, specifically WPAD and ISATAP. You’ll want to enable that second one so your IPv4 endpoints can be found using their ISATAP IPv6 addresses, so you need to remove ISATAP from the block list.
Remove ISATAP from the Block List
Before making changes, I like to know what the current settings are. Open an administrative command prompt on one of your 2008 DNS servers and run this command:
This will show you the current items on the blocklist. Generally you should only see two things: wpad and isatap. There is no way to just remove an item from this list, instead you have to reset it to the values you want, so take a look at what’s in there and then run this next command to set the new list:
Now when clinets do a DNS lookup for ISATAP the servers will actually return an answer! BTW, if you had more items in your block list just append them to the command seperated with spaces. For example, if you were blocking “wpad”, isatap” and “foo”, you would run “dnscmd /config /globalqueryblocklist wpad foo” to continue blocking everything except for isatap.
This TechNet article shows that you can also effect those changes by updating the registry, but I find the dnscmd utility to be a bit more straight forward, especially since you need to open an elevated command prompt anyway to restart the DNS Service.
If you are using any Windows 2003 servers for DNS, then you may also need to remove ISATAP from their DNS Block List. Unfortunatly the command line tool used above cannot be used on 2003 servers so you will need to edit the registry on those servers. here’s how:
- Open RedEdit on the DNS server
- Navigate to HKLMSYSTEMCurrentControlSetServicesDNSParameters
- Double click GlobalQueryBlockList.
- Remove ISATAP from the multi-string text box
- Click OK.
- Open the Services MMC and restart the DNS service.
Repeat the above process on all your 2003 Name Servers.
Effects of Enabling ISATAP
Once an ISATAP router can be found in your environment you will start to notice that some of your computers will start to respond to pings and other network traffic from IPv6 addresses. This is “normal” and by design as Windows Server 2008, R2 and Vista and Windows 7 are built to prefer IPv6. In fact, even if you uncheck the TCP/IPv6 protocol from your network adapter you’ll still see this behavior. This is because these operating systems will use a virtual ISATAP network adapter.
If you really don’t want this to happen or if it is causing a problem on one of your servers, you can do one of two things on that machine to force IPv4. That computer will then only be able to use IPv4 and DirectAccess clients will rely on the NAT64 and DNS64 features of UAG to reach that machine (if it needs to).
- Disable IPv6 using the Registry
- Disable just the ISATAP adapter using NetSh
netsh interface ipv6 isatap set state disabled
It is possible to deploy DirectAccess without enablig ISATAP, but then your internal machines would not be IPv6 enabled and would therefore not be able to reach out to the DirectAccess clients unless you deploy native IPv6 addresses in your infrastructure. If you want to learn more about how ISATAP is used with DirectAccess, Tom has a great write up on it in a post appropriately titled “Is ISATAP Required for UAG DirectAccess?”
Now you should be able to ping just about any 2008 or newer server from a Windows 7 computer and see it respond on the ISATAP IPv6 address.