Ever since Microsoft announced that Forefront Threat Management Gateway (TMG) 2010 will be discontinued, I have had many customers ask me “What should we use as a reverse proxy for Exchange?”. This question has sparked many heated debates among colleagues and customers alike. To be fair, this announcement may have come as a huge shock to many people, but I think deep down many of us expected it to happen sooner or later.. TMG was a great product and really became the de facto standard for reverse proxying Exchange (and Lync, etc) and thinking back to all the Exchange deployments I have been involved with over the years, it is fair to say that most of them made use of ISA/TMG as a reverse proxy in some way. It worked well, but sadly all good things come to an end.

So, lets get back to the question.. “What should we use as a reverse proxy for Exchange?” I’ve been thinking about this for a while and I don’t believe there is a magical silver bullet solution that will work for everyone and I urge my customers to think it through and make an informed decision. Do you even need a reverse proxy for Exchange? This is where things get heated.. but hear me out.. there are those who have been talking about the death of the DMZ for some time now. I remember attending a Tech-Ed session back in 2008 where Steve Riley talked about this and Deb Shinder has also blogged about this topic in the past. I’m not saying get rid of your firewall, but what I am saying is that perhaps you no longer need to use a reverse proxy to secure connections to your Exchange servers and this is something that should be thought about. My first response to the “What should we use as a reverse proxy for Exchange?” question is “Do you still need a reverse proxy?” and 99% of the time the answer I get back is “Yes, because it is insecure not to”. Perhaps it used to be, but is that statement still true? Every environment is different and every organisation has different needs and requirements. My intention with this post is to help you ask the right questions and make an informed decision.

One of the great things about being a consultant is that I get to work with many different types of customers and see many different types of environments and typically the decision to implement a reverse proxy is driven by one or both of the following factors:

1. Application Hardening - The concept of application hardening has been around for some time now and there is a lot of information floating around about it. The question we need to ask is: does Exchange (the CAS role in particular) need to be hardened? The reality is that times have changed and both Windows Server and Exchange have matured and are hardened by default. Exchange CAS was designed to be internet facing so there really is no need for a reverse proxy in order to secure it anymore. Sure, using a reverse proxy is useful if you wish to implement third party two factor authentication or have other very specific requirements, but will your Exchange implementation be less secure without one? probably not.
2. Security Policy - Security policy is much more complex and as you would expect, these policies come in many flavours! One thing most of them have in common is that they restrict traffic from passing through an entire zone or prevent services on the internal network from being accessed directly from the internet, i.e traffic cannot pass directly through the DMZ to the internal network, and must first terminate in the DMZ. In the past, the solution was to implement ISA/TMG as a reverse proxy in the DMZ. We already know that Exchange does not need any further hardening, so technically there is no need for this, but while technology matures relatively quickly security policies rarely keep up so it is fairly common to have this type of out-dated policy that dictates the use of a reverse proxy. Sometimes the remnants of this type of security policy are still visible long after the policy has evolved – I did some work with a customer recently who had a policy like this in the past and over time as their network grew they made decisions based on this policy that have resulted in a few technical constraints that are now causing some headaches. Typically, these security policies are similar to the diagram below:

There is something else to consider and that is performance. Often due to the mission critical nature of DMZ infrastructure and its various dependencies, this infrastructure is not upgraded or refreshed as regularly as other infrastructure so you end up building on infrastructure that was never intended to deal with the load that is now being placed on it. A classic example of this is an environment I saw a while back – this particular organisation was in the process of refreshing their messaging platform and had just made a significant investment in a highly available Exchange environment only to go and use the ageing 32-bit only ISA 2006 infrastructure in their DMZ as a reverse proxy because connections to Exchange needed to be “secured”.

So what’s answer then? Well.. I think it is important to first understand what your requirements are. Are you currently using TMG? why change? Mainstream support for TMG will continue into 2015 with extended support through 2020. Are you looking to implement a reverse proxy because you think it will make Exchange more secure? If so, perhaps you need to rethink your approach. Are you looking for a TMG replacement because your security policy dictates the use of a proxy server and you really have no choice in the matter? Here are three options:

1. F5 BIG-IP Access Policy Manager (APM)  - Many organisations have already invested in BIG-IP LTM devices to load balance Exchange. It makes sense to leverage this infrastructure, you’ll have the added benefit of infrastructure consolidation if you move the reverse proxy functionality to your BIG-IP devices. More info here
2. KEMP LoadMaster Edge Security Pack (ESP) - I have always been a big fan of the KEMP LoadMaster devices and KEMP is currently working on their Edge Security Pack which will help provide some TMG functionality and compliment their already excellent offering. These devices already provide excellent value for money and my understanding is that the ESP will be a free upgrade for most customers. ESP is not publically available yet but I think it is worth looking at. More info here
3. Apache HTTP Server with mod_proxy - No, your eyes are not deceiving you, it is possible to use apache as a reverse proxy. I am not making any claims about the supportability of the solution or saying that it is an enterprise ready option, and just because it is possible to do it does not mean you should. I have seen many attempts at this solution in the past so I am currently working on a post that will provide a guide on how to go about setting it all up as well as explain the limitations and pitfalls of the solution. I hope to post more about it soon.

I’m sure there are many other equally suitable solutions, but my intention was to mention some of the ones I have worked with or tested. Each of these also have different pricing and scalability options so they will appeal to a wide range of different organisations.