TMG Firewall Interface Configuration


There are a number of articles out there that provide advice on how to configure the interfaces on a ISA or TMG firewall. I think that’s great! The more the merrier and it’s the diversity of opinion that makes this business interesting and fun to participate in. However, it can also cause some confusion when there is missing information or when there seems to be a conflict between the various sources of information.

In this article, we’ll take a look at the interface configuration issues from the perspective of the deployment model for the TMG firewall. There are essentially three deployment models for the TMG firewall:

  • Front end firewall
  • Tri-homed (or more than tri-homed) DMZ supporting firewall
  • Unihomed (hork-mode) firewall

For each of these deployment models for the TMG firewall, we’ll talk about some interface considerations. Note that this discussion is not meant to be comprehensive, and is somewhat limited because I’m writing this while traveling and thus I don’t have immediate access to a TMG firewall and I can’t provide screenshots to highlight what I’m talking about. However, there should be enough information here to help you get up and running with planning your TMG firewall deployment.

Front-End Firewall

The front-end Firewall configuration is by far the most popular deployment option for the TMG firewall. There is a good reason for this: the TMG firewall was designed, from the ground up, to be a network edge firewall, designed to provide the same as or a better level of security than a Cisco ASA or Check Point firewall. And to that extent, the TMG firewall has done very well, showing a superior security history to both Cisco and Check Point. If you’re looking to deploy one of the most secure edge firewalls available today, you can’t do much better than the TMG firewall.

The Front-End TMG firewall will have two interfaces – one connected to the external network (the Internet) and one connected to an “internal” network of some kind. In most enterprises, the “internal” network to which the internal interface is connected is going to be some kind of stub network that summarizes the internal networks. In smaller organizations, there won’t be a stub network and the internal interface of the TMG firewall will be connected to a “live” network on the company’s internal network.

Configuring the external interface

When configuring the external interface in this scenario, you will need to configure the IP addresses that be assigned to the external interface. A single NIC can accept multiple IP addresses, so if you want to bind multiple IP addresses to the external interface, you can do that without any problems; you enter the additional IP addresses in the “Advanced” tab in the IP addressing configuration for the internal interface. You then enter a default gateway on the external interface. Do NOT enter a DNS server on the external interface. The TMG firewall should be configured to use an internal DNS server only, and that DNS server should be able to resolve both internal and external host names. How the internal DNS server does this is not a concern of the TMG firewall; you just need to be sure the TMG firewall does not have an external DNS server configured on any of its NICs.

That’s it for the configuration of the external interface (at least out of the box). There are some circumstances where you might need to do additional configuration – such as when you’re setting up a multi-ISP configuration or deploying Network Load Balancing for a TMG firewall array.

Configuring the internal interface

On the internal interface of the TMG firewall that’s being confirmed as an Edge Firewall, you need to enter an IP address. OK, that’s obvious. What I mean is that you need to add an IP address that is valid on the internal network to which it’s connected – either a stub network or an active internal network. You do not enter a default gateway on the internal interface. You never enter a default gateway on the internal interface of a TMG firewall. If you need to route to remote internal networks, then you need to add routing table entries on the TMG firewall. What’s nice with the TMG firewall is that you can enter these routing table entries during the installation of the TMG firewall – you don’t have to “try to remember” to do this before running the installation routine. Another advantage of having this as part of the TMG installation wizard is that when the routing table entries are known in advance, the TMG firewall can define the addresses that will become part of the default Internal Network automatically.

You will also need to enter one or more DNS servers on the internal interface. In general, it’s a good idea to enter more than one, just in case the primary DNS server becomes unavailable. These DNS servers need to be able to resolve both public and private names (the private names being the names of resources on your corporate network). The internal DNS servers will also need a way to resolve public names too. There are a number of ways that you can configure your internal DNS to resolve public names and you probably already have these in place. If your DNS servers are going to access public DNS servers through the TMG firewall, make sure you create an Access Rule that allows the DNS servers outbound access to the DNS protocol to the default External Network.

Interface order

After you configure the internal interface, make sure to move the internal interface to the top of the interface list. You can do this in the Network Connections window by clicking on the “Advanced” menu. The figure below shows the “Advanced Settings” dialog box on a Windows 7 machine, but it will look similar to what you see in a Windows Server 2008 R2 machine, where you configure the settings on the TMG firewall computer. Just use the arrow buttons to move the internal interface of the TMG firewall to the top of the interface list. This will speed up your DNS name resolution behavior.

Figure 1

The reason why we’re so concerned about the TMG firewall being able to resolve public host names is that when you configure internal hosts to be Firewall and Web Proxy clients (TMG clients are the same as Firewall clients), these client types allow the TMG firewall to resolves names on their behalf. If the Firewall and Web Proxy clients can’t depend on the TMG firewall to resolve these names on their behalf, name resolution will fail and the Firewall and Web Proxy clients won’t be able to resolve names and connectivity will fail in a variety of ways, depending on your unique environment.

That’s all for the Edge Firewall Configuration. If there are three take-away messages that you should remember at all times when it comes to the Edge Firewall configuration, it is these:

  • Never put an external DNS server on any of the interfaces of the TMG firewall,
  • Never put a DNS server address on the external interface of the TMG firewall, and
  • Never put a default gateway on the internal interface of the TMG firewall.

Tri-Homed (or Multi-Homed) TMG Firewall

The tri-homed (or multi-homed) TMG firewall is similar to the Edge Firewall, in that it has an external interface and an internal interface. However, in addition to the external and internal interfaces, it has additional interfaces. These additional interfaces can be DMZ interfaces or additional internal network interfaces.

When we think of DMZ interfaces, we typically think of these as interfaces connecting to networks that provide access to Internet facing computers. The additional internal interfaces might be other networks that are connected to the TMG firewall that contain internal hosts that are not Internet facing.

When configuring the NICs on the DMZ interfaces, you configure them with valid IP addresses for the networks to which they’re attached. You do not configure them with DNS server entries or default gateways. In addition, you do not move them to the top of the interface list as we did with the internal interface of the TMG firewall. You will need to configure the appropriate subnet mask, as you need to do for all interfaces connected to the TMG firewall.

The same is true for any additional internal interfaces you configure on the TMG firewall. For the additional internal interfaces, configure them with the appropriate IP addresses and subnet masks. As with the DMZ interfaces, do not configure them with DNS server settings or default gateways. If you need the networks to connect to remote networks on that interface, use the TMG firewall console to add new routes on the TMG firewall so that the firewall will know the next hop to reach the remote networks.

As you can see, configuration of the DMZ and additional internal networks is very similar to that of the front end firewall configuration, and not complex. There’s no need to get tricky or think that there is some “secret sauce” that’s required for configuring these interfaces. When it comes to configuring DMZ and additional internal interface NICs, the operating principle is “Keep It Simple, Silly” :).

Unihomed “Hork Mode” TMG Firewalls

The single NIC TMG firewall is sometimes called a “hork mode” firewall (at least that’s the term Tom made popular in writing about this configuration) because a single NIC TMG firewall has much of its functionality and security feature set removed. It’s a little like buying a Ferrari and then taking three tires off of it because the car “goes too fast”. Nevertheless, there are many organizations that want or need to deploy a hork mode TMG firewall and therefore we need to make sure that the NIC on the firewall is configured correctly.

When you configure a unihomed TMG firewall, you need to understand that the concept of internal versus external networks is gone. For the unihomed TMG firewall, all networks are considered internal. Because the TMG firewall doesn’t trust any network, this isn’t as bad as it seems – the TMG firewall doesn’t trust an internal network any more than any other network, so you don’t have to worry about intruders “partying down” on your hork mode TMG firewall just because it sees the entire IPv4 address space as internal.

When you configure the NIC of the unihomed TMG firewall, you need to assign it a valid IP address. This address will be used for outbound access (forward proxy) and inbound access (reverse proxy). If you want to publish multiple web sites with the unihomed TMG firewall, then you can assign multiple IP addresses to this NIC. You will want to make sure that you reverse one of the IP addresses to the web proxy listener if you want the listener to listen on TCP port 80. However, the default value is TCP port 8080, so if you go with the default, you won’t run into problems with your web publishing scenarios.

You also need to enter a default gateway and any routes to remote internal networks on your internal network. Again, these routes can be entered as part of the installation routine – however, in the case of the unihomed TMG firewall, these routes won’t be used to determine the address space for the default Internal Network, since all IPv4 addresses are considered internal for the unihomed TMG firewall.

An internal DNS server (or servers) also needs to be configured on the NIC for the same reasons they need to be configured on the internal interface of the Edge Firewall. However, in this case, the TMG firewall will not be resolving names for Firewall clients, since hork mode TMG firewalls do not support firewall clients; they only support web proxy clients.

That’s about all you need to know to configure the interface for the unihomed TMG firewall. There are no issues related to moving the NIC to the top of the interface list, because there is only a single interface on that list. However, as with other NICs, never enter a public DNS server address on the unihomed TMG firewall’s NIC.


In this article, we discussed some issues related to the NIC (interface) configuration on the TMG firewall. We broke the interface configuration down for three different scenarios: edge firewall, multi-homed firewall and unihomed TMG firewall. While there are similarities for all three scenarios, there are some specific issues that need to be considered for each scenario.

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