Replacing Forefront TMG: Alternate reverse-proxy options for Exchange

With the discontinuation of Forefront TMG, Exchange admins are left wondering what to do moving forward. The available options may surprise you.

A secure reverse proxy to publish Exchange is a must-have for many companies. Historically, the recommended go-to...

has been Microsoft's Forefront TMG Server, a combination firewall, VPN, Web proxy and reverse-proxy product. At the end of 2012, however, Microsoft announced it was discontinuing the product. Whether you've already deployed TMG, or are looking for a new reverse proxy, a simple question stands out: "What do I do now?"

Now, before examining reverse-proxy alternatives, it's important to distinguish between a load balancer and a reverse proxy. The primary job of a load balancer is to spread incoming connections among multiple application servers. The primary job of a reverse proxy is to terminate incoming connections from untrusted networks and to create a new connection into the application server.

This line is blurring today, and it's important to understand that both feature sets are often found in the same appliances and software packages. For example, Forefront Threat Management Gateway (TMG) is technically a reverse proxy, but the Web farm functionality provides HTTPS load balancing, as well.

Now, onto those alternatives:

Keep it if you've already got it

If you've already deployed Forefront TMG -- and it is meeting your needs -- don't rush to replace it. Microsoft has committed to maintenance and support for TMG through the end of 2015. The Exchange team has made it clear that TMG will continue to be a good choice for existing deployments. In fact, they even provide guidance on adapting it for Exchange 2013.

Unless you have a reason to replace or expand your TMG deployment, my advice is to stick with it. Alternatives are slim right now, but vendors are working on filling this new gap in the Exchange ecosystem. In other words, a "wait-and-see" approach makes a lot of sense.

Don't use a reverse proxy

Do you even need a reverse proxy? This might seem like an obvious question, but I'm continually surprised by the number of companies that deploy a reverse proxy without a clearly defined set of requirements.

The most common reverse-proxy drivers I've seen come from regulatory requirements that mandate separate security zones. However, even that may depend on your auditor's understanding of the technical issues.

Reverse proxies provide extra security, single sign-on, pre-authentication, SSL offload and also consolidate multiple hostnames to the same IP/SSL certificate. If you have a solid firewall and only allow minimal connections into your Exchange client access server roles or load balancer, reverse proxies are not essential. Many companies -- including Microsoft -- run this way.

Use an extended load balancer

Even before Microsoft formally announced it would stop selling Forefront TMG, many load balancer vendors were already working on extending their products' functionality. Remember, load balancing is only a small component of application publishing. Of the various load balancers that work with Exchange Server, two in particular are worth investigating:

  • F5 has created the high-end BIG-IP LTM appliance family, which combines firewall, traffic management and sophisticated application deployment capabilities. With the Access Policy Manager software module, BIG-IP LTM devices provide a variety of functions that have traditionally been performed by reverse proxies, such as pre-authentication, Active Directory awareness and advanced authentication options like client SSL certificates and Active Directory Federation Services integration.
  • For less-complex deployments, Kemp technologies makes a simple, easy-to-use and powerful line of load balancers that are tuned for publishing Exchange, Lync and other common applications. Although it is still in beta, Kemp provided the Edge Security Pack, which extends the capabilities of Kemp products to include reverse-proxy functions such as pre-authentication and single sign-on.

F5 and Kemp are both highly recommended in the Exchange community, but are far from the only load balancer vendors. If you already have a different product deployed, check with your vendor to see what reverse-proxy functionality it has available, or is planning to make available soon.

Create your own reverse proxy

The final option is to devise your own reverse proxy. Many open-source applications and technologies exist that provide the basics you'll need. Of course, this is based on the idea that you're willing to do some research and experimentation, and live outside of official support boundaries.

Consider the following:

  • The Apache Web server provides a number of modules that allow you (in theory) to create a sophisticated custom reverse-proxy configuration.

    Note: In reality, you may end up needing to use an old, insecure version of Apache if you need to support Outlook Anywhere. Current versions seem to have problems handling the RPC over HTTP component.
  • The Squid reverse-proxy package may also be configured to work with Exchange Server. That said, many users report difficulty getting Squid to work correctly while upgrading to a new version of Exchange.
  • The NginX reverse-proxy package is expected to work with Exchange Server, overcoming many of the difficulties reported with both Apache and Squid.

In order to use these custom packages, you may need to use Linux as the base operating system for the reverse-proxy server. While most of the software packages are available on Windows, many modules or technologies required for optimal performance and functionality may not work as expected.

A word to the wise: Research, test and prepare to spend plenty of time supporting any custom reverse-proxy configuration. Going this route may give you exactly what you need, but you will also be responsible for troubleshooting and fixing any issues that come up.

As you can see, there are a variety of alternatives to TMG. At the end of day, however, it's up to you to understand exactly what you need, why you need it and what your ongoing support requirements are. Use that data to guide your decision.

About the author:
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems and Windows, Unix and TCP/IP networks. Today, he works primarily with Exchange Server, Windows Active Directory and related Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.

Dig Deeper on Exchange Server setup and troubleshooting