Considerations for Replacing your TMG Firewall (Part 5)

If you would like to be notified when Deb Shinder releases the next part in this article series please sign up to our Real-Time Article Update Newsletter.

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


In this multi-part series on the features that you should consider when you start evaluating new firewalls to replace the TMG firewall at some point in the future, thus far we have discussed inbound and outbound SSL bridging, pre-authentication and delegation at the web proxy server, and the remote access VPN server and site to site VPN gateway functionalities. In each of those articles, I talked about what the key capabilities are for the particular feature in question, and the questions you need to ask about the new firewall replacements that you’ll be considering, in order to determine whether it will adequately serve your needs.

As a reminder, here is our list of TMG firewall capabilities that we started with in the introductory article of this series:

  • Inbound SSL Bridging
  • Outbound SSL Bridging – SSL inspection
  • Pre-authenticating and delegating Web Proxy
  • SSTP VPN Server – remote access client VPN server
  • Site to Site VPN server
  • Winsock Proxy
  • URL Filtering
  • Web Antimalware
  • Multi-ISP connectivity
  • Network Load Balancing – HA support

This time, we’re going to finish up the story by taking a look at the last four features that I believe are important for you to consider as part of your evaluation process for a replacement of your TMG firewall.

URL Filtering

Back in the ISA firewall days, we used to play an interesting game with the ISA firewall admins out there. If you were involved with ISA in those days, you might remember that we made a big deal of the ISA firewall being an application layer inspection firewall. Well, that was true to a greater or lesser extent, but most of the people who wanted application layer inspection wanted some inspection of the URLs that the internal clients were requesting, and wanted to then be able to block and allow connections based on the URL that was requested.

Of course, you could do that to a certain extent with the ISA firewall by using Domain Name Sets or URL sets. The problem was that while you could do this, you had to figure out which domains to block or allow; there was no automation available. That meant you had to find your white lists or black lists and then you had to put them into a format that the ISA firewall was able to use, and then you had to import them into the ISA firewall configuration. To say that this was a bit tedious doesn’t do justice to the actual feelings that were experienced by ISA admins.

So you can imagine how happy those ISA firewall admins were when TMG was released, complete with URL filtering! No longer would the ISA firewall admins have to use a third-party application to control access based on URL to automatically block dangerous or compromised web servers. Even better, the cost of the URL filtering with the TMG firewall was very low in comparison with the comparable offerings from companies such as Websense.

The TMG firewall’s web filtering feature is somewhat basic, but I’ve found that most organizations only really need or want this basic type of filtering. The URL filtering feature allows you to block URLs based on categories and it allows you to move URLs to different categories if you don’t agree with the out-of-the-box categorization. You can also create new categories and you can submit URLs for categorization if the URL isn’t in one already. In addition, you can test to determine whether a URL is already in a category before using it in a rule. This functionality is more than enough for many orgs.

If this is something that you’ve been depending on with your TMG deployment, make sure to put web or URL filtering capabilities near the top of your list when you’re considering a replacement for your TMG firewall.

Web Antimalware and Network Inspection System

The Holy Grail of application layer inspection seems to be web anti-malware. That makes sense. After all, where does most of the malware come from these days? Floppy disks? No. CDs? Unlikely? DVDs? Probably not. USB sticks? Sometimes. The web? Every day! We know that security is a constant battle these days, and if you can’t block malware from being downloaded to your systems from malicious web sites, you’ve already lost the war.

That’s what’s great about the web anti-malware solution that comes with the TMG firewall. The definitions are automatically downloaded every day, and often several times a day. The anti-malware engine also automatically updates itself, and in most cases, the engine and definitions are more up to date than those that are found on the hosts located behind the firewall. In addition, there might be a number of machines behind your TMG firewall that have no anti-virus software installed on them. In these cases, the TMG firewall’s anti-malware capabilities could be their only line of defense.

When looking at replacements, it’s important that the web-antimalware solution be able to inspect the contents of SSL connections. As I discussed in an earlier article, much of today’s sophisticated malware is able to leverage the fact that most firewalls are unable to view what’s happening inside an SSL tunnel. Malware writers are aware of this and so they make sure, when they install malware on systems, that the malicious software is able to make call-backs to a server through an SSL connection. At that point, they can use the SSL tunnel to download more malware, all without the firewall having any idea of what is going on.

The TMG firewall’s anti-malware feature works together with its outbound SSL inspection feature to ensure that malware will not be able to hide inside an SSL tunnel. When the TMG firewall acts as a “trusted man in the middle,” it is able to view and clean the contents of the SSL communications. For best security, make sure that your TMG replacement is able to do the same thing.

In addition, you are probably going to want to have some kind of IPS/IDS system in place. The TMG firewall has the Network Inspection System (NIS), which can detect protocol anomalies and patterns that suggest established and potential zero-day exploits. Make sure that the new systems you’re considering have something comparable.

Multi-ISP connectivity

I remember back in the ISA firewall days, even way back to the year 2002, when the ISA firewall admins said “this is great, but I have to have connections to multiple ISPs for high availability and bandwidth aggregation.” They kept saying that after ISA 2004 was released and they said it even more often when the ISA 2006 firewall was released. It seemed as if we’d never get multi-ISP support!

When the TMG firewall came out, after waiting four years after the release of the ISA 2006 firewall, we finally got it! With the TMG firewall, you are able to connect the firewall to two ISPs. You can use those connections to aggregate bandwidth and you can use them for failover to provide high availability for your Internet connectivity. We would have preferred a solution that allowed for more than just two ISPs, since bandwidth requirements over the years have really exploded, with cloud computing becoming so important. But I’ve found that many mid-sized and even small businesses (depending on where they’re located) are often able to get connections with 50Mbps and bind them with the TMG firewall to provide them over 100Mbps of Internet connectivity at essentially commodity prices. That’s a far cry from the 128Kbps connections over ISDN that we were using at the beginning of the 21st century!

Network Load Balancing – HA support

While high availability for the Internet connections is great and extremely important, it’s not much use if you don’t have high availability for the firewalls themselves. If one of the firewalls dies, you have to ensure that there are one or more there ready to take over the duties. Fortunately, the TMG firewall supports multiple firewalls in what we call arrays.

Arrays are very useful for a number of reasons. First, of course, they provide for high availability. If one of the TMG servers dies, others in the array can take over for the downed firewall. Second, arrays can be configured as sort of a single “virtual” firewall. You make the configuration on one of the firewalls in the array and the configuration is automatically distributed to all other array members. This makes management easier. Finally, each member of the array can use the same IP addressing information on its internal and external interfaces, so that both inbound and outbound connections can continue to be available if one or more firewalls in the array should become disabled. This is done using the Windows Network Load Balancing (NLB) service.

Of course, you also have the option of using an external load balancer, but that is much more expensive. If you already have one, then go ahead and keep using it. But if you don’t already have one, and you want an on-box solution, make sure that your replacement for the TMG firewall includes some kind of load balancing feature right out of the box.


We’re getting close to the end of the line for our beloved TMG firewall. We’ve been fans of the firewall since ISA 2000 and it’s hard to say goodbye, but all good things must come to an end. However, we’re not there yet. Our TMG firewalls will continue to work and provide service until the year 2020, so there is time to think through what your requirements will be when it’s time to replace the firewall. In this article series I provided what I thought were important features in the TMG firewall that you’ll want to make sure to include in your TMG firewall replacement. However, keep in mind that these features are important in the world of networking that we live in today. I’m sure as time goes by, networking technologies will change, threats will change, user and corporate requirements will change and you’re going to need to stay abreast of these changes and think about how they will affect your decisions in choosing a new firewall. Until then, I’ll continue to write articles about the TMG firewall until they pry it from my cold, dead hands! See you next week! –Deb.

If you would like to be notified when Deb Shinder releases the next part in this article series please sign up to our Real-Time Article Update Newsletter.

If you would like to read the other parts in this article 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