If you would like to read the first part in this article series please go to Troubleshooting TMG SecureNAT Clients (Part 1).
Introduction
In Part 1 of this two-part article, we began the discussion of how to troubleshoot problems with the TMG SecureNAT client, including issues related to complex protocols, problems with accessing web sites, and problems you might have accessing all protocols. Another big area of potential problems is name resolution, so in this Part 2 we’ll talk about some of the common problems that center around DNS, depending on the location of the DNS server (internal or external network).
Name Resolution Problems
The first thing you need to understand regarding name resolution is that the SecureNAT client cannot use the TMG firewall to resolve names on its behalf. This is in contrast to the behavior of the Firewall and Web Proxy clients, both of which can offload their name resolution process onto the TMG firewall. Because you don’t have that luxury with SecureNAT, you’re going to need to configure each of your SecureNAT clients with the address of a DNS server. The DNS server can be one that resides on your internal network or you can use a DNS server on the Internet.
The potential problems with name resolution for SecureNAT clients will differ, depending on whether the SecureNAT client is configured to use:
- A DNS server on the internal network
- A DNS server on the Internet
Let’s look at each of the scenarios and their resultant issues in more detail.
DNS Server on the Internal Network
If the SecureNAT client is configured to use a DNS server that’s located on the internal network, you must ensure that the DNS server will be able to resolve names for Internet hosts. Of course, most Windows DNS servers are able to issue iterative queries to Internet DNS servers as long as the cache.dns file on the DNS server includes the names of the Internet Root Servers.
A Windows DNS server can also be configured to use Forwarders that can resolve Internet host names on the behalf of the internal DNS server.
If you have configured the SecureNAT client to use an internal DNS server, you first need to check to see whether the DNS server is able to resolve Internet host names. If the internal DNS Server cannot resolve Internet host names, and it has not been configured to use a Forwarder, then consider the following possibilities:
- The internal DNS server may have been configured as a Windows Active Directory Domain Controller and DNS was configured using the Active Directory DNS configuration wizard
- The internal DNS server might not have access to a Protocol Rule that allows it to send DNS queries through the TMG firewall
Okay, so what do we do about those problems? Let’s break each one down a little further.
Internal DNS Server is an Active Directory Domain Controller
The problem that comes up when the internal DNS server is an Active Directory Domain Controller (DC) is related to some of the limitations that are built into some versions of the Active Directory DNS wizard. Here’s what happens: If, during the setup process for the DC, the wizard is not able to contact one of the Internet Root Domain servers, then the DNS wizard will configure the machine to be a root server. When this occurs, the wizard fails to populate the Root Hints file with the names and IP addresses of the Internet Root servers. This, in turn, prevents the internal DNS server from sending any queries to Internet DNS servers in order to resolve Internet host names.
Luckily, there are two ways that you can solve this problem:
- You can manually configure the zone prior to promoting a machine to a domain controller. If a root zone appears as a “.”, you can delete that zone and then restart the computer.
- You can make sure that the machine being configured as a DC will be able to access the Internet during the Active Directory setup process, so that a root zone will never be created.
The first option requires you to manually configure the zone prior to running the dcpromo command on the machine that you’re configuring to be a DC. There are a few caveats that you need to be aware of. First, make sure that the zone is able to accept dynamic updates and make the zone a Standard Primary zone. After the dcpromo process has completed, the computer will restart. If the wizard was not able to contact an Internet Root server during the process, it will create the bogus Root “.” domain zone. If you see that has happened, you can delete that zone and then configure the machine so that it can perform DNS queries to Internet servers.
The second option is a little more proactive, as it allows you to get around the whole problem in the first place. In this case, make sure that before you run dcpromo, you’ve ascertained that the machine is able to perform DNS queries on the Internet. You will need to create a Protocol Rule that will allow outbound UDP Port 53 messages to pass through the TMG firewall and that will allow the DC machine to use that Protocol Rule.
The Internal DNS Server is not able to Query an External DNS Server
Sometimes you’ll run into a problem whereby the internal DNS server is not able to query an external DNS server. When this takes place, the most likely reason is that the TMG firewall has blocked outbound access to the DNS protocol. That can happen in one of two ways. Access might have been blocked explicitly by a Deny rule, or there might be no Allow rule to allow access. In either event, access to the DNS protocol is blocked so the internal DNS server won’t be able to contact the external DNS server.
The solution to this problem is pretty easy; you just need to configure an Access Rule that will allow outbound access to outbound UDP Port 53.
Make sure that you test your DNS configuration on the DNS server first. Here’s how to do that:
- Use the nslookup command.
- Issue an nslookup query by opening a command prompt and typing the command:
nslookup www.somedomain.com.
Important:
Remember to include the trailing period after “.com,” because if you don’t, nslookup may treat the request as if it’s an unqualified query and append its own domain name to the request, and that’s not what you want.
The Internal DNS Server is Configured to Use a Forwarder
You already know that the internal DNS server can be configured to use a Forwarder. The Forwarder will resolve the request for the internal DNS server, thereby offloading the iterative query process away from the internal DNS server. Sometimes, though, the internal DNS server might not be able to contact the Forwarder. If the machine has problems contacting the Forwarder, you need to make sure that there is a Protocol Rule that allows DNS queries. In addition, you should check to be sure that you’ve entered the IP address for the Forwarder correctly. Sometimes the problem is as simple as a typo.
The SecureNAT Client is Configured to use a DNS Server on the Internet
If the SecureNAT client is configured to use a DNS server that’s located out on the Internet, and you’re having name resolution problems, you should check to make sure that the SecureNAT client has access to a Protocol Rule that allows outbound DNS queries. This is another one of those cases where “fat fingers” (typographical errors) can do a lot of damage, so always double check to verify that the IP address of the Internet DNS server is correctly configured on the SecureNAT client.
Summary
The SecureNAT client is the preferred configuration for TMG clients that run non-Microsoft operating systems, such as Linux or Mac OS X. There are also situations where you’ll want to configure Windows clients as SecureNAT clients. However, there are problems that can occur and prevent your SecureNAT machines from working properly, so you need a basic understanding of how to troubleshoot the most common of these problems to identify the cause and resolve the problem. In most cases, it’s pretty easy to fix the problem once you’ve figured out what it is.
In this two-part article, we’ve taken you through the steps for troubleshooting SecureNAT problems related to complex protocols, accessing web sites, accessing all protocols and name resolution problems that can stem from DNS configuration.
If you would like to read the first part in this article series please go to Troubleshooting TMG SecureNAT Clients (Part 1).
