TMG Firewall Name Resolution (Part 1)

If you would like to read the other parts in this article series please go to:


If you’ve worked with it before, you know that TMG can be a very easy firewall to stand up and put in production. However, that simplicity can backfire on you if you don’t know what you’re doing. That’s because, while the TMG firewall is easy to install and configure, there are a number of back end issues that need to be handled before you will be able to get the most out of your TMG firewall. These back-end requirements need to be addressed before you even begin the installation process, while you’re still in the stage of planning your deployment.

The most important reason for getting these back-end services up and running and tuned correctly right up front is so that you can get the best performance possible out of the TMG firewall. If any of these back-end services are misconfigured, you can see significant reductions in the overall performance of the solution. And while the TMG firewall has mechanisms that can correct to a certain extent for inefficacies, the best way to avoid having to call on these mitigations is to get things done right in the first place.

Before you begin your installation and configuration trek into the TMG firewall, you should address key issues in name resolution. The rest of this article will be focused on name resolution issues.

Resolving Names in the World of the TMG Firewall

One of the most common reasons for the TMG firewall to perform poorly is related to problems with name resolution. If the TMG firewall cannot resolve names quickly, using your current DNS and potentially NetBIOS infrastructure, then requests are going to be returned very slowly or in the worst case scenario, not at all. Therefore, we need to think about what has to be done to support TMG’s name resolution functionality.

There are a number of functions in which name resolution is a key piece of the TMG firewall’s functionality. These include the following:

  • Policy evaluation
  • Windows name resolution
  • Internet name resolution
  • Internet name reverse lookups
  • NetBIOS name resolution
  • Naming services performance

Policy evaluation 

Computers, as binary beings, like to “think” in terms of numbers. But we human types tend to prefer working with easier-to-remember names. You can configure the TMG firewall to use names in firewall rules. But of course, when the TMG firewall is set up to use names in firewall rules, the TMG firewall will need to be able to resolve the name that’s in the firewall rule to the IP address associated with that name. This is important, because if the TMG firewall can’t resolve the name that’s included in a policy rule, then the connection attempt will fail.

TMG maintains its own name cache to improve name and IP address lookup performance, but TMG depends on Windows to perform the initial name or IP address resolution. Thus, the efficiency of traffic evaluation is directly proportional to the efficiency of the underlying Windows name-resolution mechanisms. There are times when the TMG firewall will be able to resolve the name, but if the name resolution process is very slow, and if that name is not included in the TMG firewall’s DNS cache, then the perceived performance of the firewall will be that it is slowing things down. This is one of the most common reasons for users to complain about the “Internet being slow” and for administrators blaming the TMG firewall for the slowness. While there are situations in which it might be the fault of the TMG firewall, in most cases it’s actually a problem with the back-end DNS name resolution.

Windows name resolution configuration 

The TMG firewall does not have a special name resolution client. Instead, it uses the DNS client that is built into the version of Windows Server that the TMG firewall is installed on. This can be a problem if you have chosen to use the default Windows DNS client configuration. The reason for this is that while the default Windows DNS client configuration is useful for a standalone operating system, it’s not the best configuration for the TMG firewall. Therefore, you are going to need to reconfigure the DNS client behavior on the TMG firewall if you want to get the best performance from the firewall.

Because the majority of traffic that’s handled by the TMG firewall is HTTP-based and destined for the Internet, Windows is configured as a NetBIOS hybrid node by default. This means that if Windows has DNS and WINS services available to it and DNS and WINS queries fail to provide an authoritative success or failure response, Windows will fall back to NetBIOS name broadcasts. This process of cycling through the various methods of name resolution takes time, and it can take a quite a bit of time if you have to wait for both the DNS and NetBIOS name resolution sequences to time out.

Internet Name Resolution

Most of the requests that go through the TMG firewall are going to be for Internet host names, so the TMG firewall will need to be able to resolve those Internet host names. And while most of the requests made to the TMG firewall are going to be for Internet host names, the TMG firewall itself needs to be able to resolve both Internet host names and internal network host names. The TMG firewall needs to be able to resolve internal network host names so that it can access supporting services on the intranet as well as when you are using the TMG firewall to allow users to access internal resources that might be on other network segments.

Internet name resolution will need to be accomplished by configuring the TMG firewall to use one or more DNS servers that can resolve Internet host names. Since many organizations do not allow their client systems to resolve Internet host names, the internal DNS servers are most likely not going to be configured to resolve Internet host names. That means you might need to stand up some DNS servers on your network that can resolve Internet host names in order to support the TMG firewall.

Internet Name Resolution Reverse Lookups

In addition to needing to resolve Internet host names, the TMG firewall also needs to be able to perform reverse lookups on the IP addresses that are sent to the TMG firewall. The reason the TMG firewall needs to be able to perform reverse lookups is because a user might send a request to an IP address of a host to which you don’t want users to have access. If the TMG firewall is configured to block a particular site by name, and the user enters the IP address of the site instead of the name, then the TMG firewall will perform a reverse lookup and determine whether that site should be allowed or not allowed.

There’s a problem here, though. Reverse name resolution issues can lead to some performance problems if you depend on a lot of reverse name resolution. In most cases, users are going to be using FQDNs to access Internet resources, and in that case, users should not encounter too many problems in this area. But if your users are required to use IP addresses to access resources, and if the PTR records are not properly configured for those addresses, then this can lead to a significant performance degradation for these requests. There’s not a lot you can do about this because organizations maintain their own DNS databases, and about the only thing you can do is ask the owners of the domains (nicely) to update their reverse lookup zones.

NetBIOS Name Resolution

Remember that the TMG firewall uses the operating system name resolution client to perform name resolution. As we mentioned earlier, Windows has been designed to fall back on NetBIOS when DNS name resolution fails. That means you are going to need to consider exactly what the effects of NetBIOS name resolution are going to be on your deployment. In general, you should want to minimize the effect of NetBIOS name resolution on the overall performance of the TMG firewall’s ability to resolve names. One way you can do this is by addressing issues with NetBIOS broadcast traffic.

Broadcast traffic is not used on the Internet, of course, and because TMG blocks NetBIOS broadcast traffic by default, you can expect that NetBIOS broadcasts will fail for name resolution, even on the internal network. However, because of the way the NetBIOS name broadcast mechanism operates, it can take up to a minute for NetBIOS name resolution to fail. That might not sound like a long time, but it can cause significant delays or even failure for TMG traffic processing. But that’s not all. Because TMG also logs these broadcast packets, additional processing overhead is going to be incurred for traffic that has already caused traffic processing delays. Ouch.

So what do you do? The best way to stop NetBIOS broadcast traffic (and significantly improve TMG’s performance by doing so) is to configure Windows as a peer-node host. You can do that by using the following registry value:

Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters
Name: NodeType
Value: 2

This peer node host configuration will stop NetBIOS broadcasts and will require that the TMG firewall use a WINS server to resolve names. Note that because this change affects a Windows kernel-mode networking component (NetBIOS over TCP/IP), it does not take effect until the computer is rebooted, so you’ll need to restart after making the registry edit.

Performance of Name Services 

When the TMG firewall is required to process traffic based on the destination name, the name resolution requests may put a heavy load on your existing DNS name servers. The good news is that TMG’s internal name cache helps reduce the amount of stress put on the DNS servers. However, in cases where the name is not in the cache, the TMG firewall has no choice but to send the name resolution request for each request that doesn’t have a name in the cache already to the DNS servers. There is a solution for this. You might want to consider creating DNS servers that are dedicated to the TMG firewall. This reduces the load on those name servers that are used by the internal network hosts and it also decreases the response time for TMG name queries. The dedicated DNS server should be installed on the internal or perimeter network and you will need to allow it outbound access to Internet based DNS servers.

Remember that if the name-lookup load TMG generates for your DNS servers is especially high, it might cause the name resolution process for internal resources to be delayed or even fail. This is a very bad thing, as it can cause internal network clients to have disrupted network connectivity and we all know that means complaints and calls to tech support. These types of errors can sometimes be difficult to troubleshoot, so it’s better to be proactive and head off this situation by providing the TMG firewall with its own DNS name resolution servers.

You might be considering installing a DNS server on the TMG server itself. That seems like a logical way to cut costs, but going this route can cause performance issues, too, so in general you should avoid this and create a separate DNS server.


In this article, we discussed a few of the important considerations you should make before installing the TMG firewall, specifically focusing on name resolution issues. Name resolution is critical to good TMG firewall performance. If you find that your TMG firewall isn’t performing as well as you think it should, one of your first steps should be to check out the name resolution environment and make sure that you’ve optimized it for the TMG firewall.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top