Firewalls Between Exchange Servers? Not On My Network!

So I am currently working with a customer on their Exchange 2003 to 2010 upgrade, and the security team decided to get involved in the initial architecture designs, which is good, but they insisted we deploy a network architecture that is not supported, which is bad.

They wanted us to deploy Exchange 2010 in a multiple tiered network, where the Edge Transport and TMG 2010 servers sit in the outermost DMZ and accept connections from the Internet, the CAS and Hub Transport servers sit in a middle DMZ, separated from the Edge and TMZ by one set of firewalls, and from the mailbox servers on the inside by another set of firewalls. Essentially, they want it to look like this:

Which quite frankly is not only a bad ideal, it is also explicitly not supported by Microsoft. The security team challenged me on this, and made some very valid points regarding the benefits of a multi-tiered design and separation of roles, but at the end of the day, you never want to deploy something in a fashion that the vendor states is not supported and tells you not to do. In case any of you find yourselves in a similar situation, I wanted to lay this out for you, provide links to more information, and hopefully save you some pain in suffering either when dealing with the security folks, or conceding their point and then finding yourself being told by the very nice support engineer that you are up the creek, without a paddle.

Since the fear is that the CAS server role is the one that must accept connections from the Internet, all the documentation is around the CAS role. The same restrictions hold true for Hub Transport, Mailbox, and UC roles, but since those don’t deal with Internet traffic, surely no one is thinking to put a firewall between them and the rest of the network, are they? </sudders>

What’s the problem

Exchange 2010 was designed with only one role planned to be separated from the network by a firewall-the Edge Transport server role. CAS, Hub Transport, Mailbox, and Unified Messaging roles are all installed on domain members, make heavy use of RPC to communicate with all other Exchange servers in the organization, and the product was not tested with firewalls separating any Exchange role other than the Edge Transport from the internal environment. When you put a firewall between an Exchange server and the rest of the internal network, you are restricting network access for a product that was built around having unrestricted access.

Why isn’t this supported?

The bottom line is because this isn’t how the product was built to work. Since it isn’t built to work this way, Microsoft won’t test usage scenarios with firewalls separating Exchange roles, and that means it’s not a supported configuration.

Exchange 2003 supported it

Yes, it did. Feel free to stay on 2003 if you wish to do so. Exchange 2007 and 2010 are radically different from 2003, the CAS role is significantly different in function from the FE server in 2003, and things change.

Then what should I do?

If you do not want Internet traffic going straight through to your CAS server (and I don’t blame you one bit for that) publish it through a reverse web proxy, like Microsoft TMG 2010. That is fully supported, and is the intended way to provide secure access to the CAS resources from Internet clients.

I’m doing it anyway

Good luck with that, let me know how it works out for you. You probably want to see this TechNet article, Exchange Network Port Reference and consider the following words of wisdom from an Exchange team member’s blog…

Not supported, means not supported

If you call into PSS and the support engineer you are working with finds that your Client Access Server is in a restricted or perimeter network, you are deemed unsupported.  This does not mean that the PSS engineer hangs up the phone and says “too bad” right off the bat.  What this does mean is that the Engineer will gather logs and attempt to better understand your issue.  If at any point during troubleshooting, the PSS Engineer feels your issue may be caused by, or complicated by, the Client Access Server being in the perimeter, the engineer may request that troubleshooting be suspended until the Client Access Server in question be moved into the internal network.  If the customer is not willing to do this, then the customer is at that point unsupported by Microsoft PSS. From http://blogs.msdn.com/b/brad_hughes/archive/2008/05/05/how-not-to-deploy-client-access-servers.aspx

That sucks. Microsoft should do X

I’m not here to argue that point with you, or defend Microsoft’s decisions. The purpose of this article it to help make it clear to security professionals that this is the way it is, and if the organization wants to deploy Exchange 2010, don’t deploy it with firewalls between the CAS servers and other internal resources. Reverse proxy it, or pass the Internet traffic straight through, or cut off all Internet access and make your clients go through a VPN first. Personally, I’ll opt for the TMG approach every time.

Written by Casper Manes

I currently work as a Senior Messaging Consultant for one of the premier consulting firms in the world, I cut my teeth on Exchange 5.0, and have worked with every version of Microsoft’s awesome email package since then, as well as MHS, Sendmail, and MailEnable systems. I've written dozens of articles on behalf of my past employers, their partners, and others, and I finally decided to embrace blogging and social media, so please follow me on Twitter @caspermanes if you enjoy my posts.

2 Comments

  1. Roger Willson · July 17, 2012

    It’s hard to communicate when features somebody liked and used in the past are not available in new releases, no matter what the reasons for this are. In such cases it feels the new version is inferior to its predecessors. Though you are right that especially this firewall thing is too risky to have, so it’s logical why it got removed.

  2. Candice Telano · July 25, 2012

    We, technology users, sadly speaking, should abide with vendor guidelines on the use of their products or services, or face the brunt of not getting the adequate amount of support from them when push comes to shove. So, yeah, like it or not, don’t do it if it’s not supported.

    I have written so many times about zealousness and proportionate preparation. It is all about using just enough resources for your purpose. Don’t overdo it or risk tipping off the balance between cost and benefits.

    It’s all about security, you say, and that there should be no-holds-barred moves to protect data and resources, you say. Nope, again, always, it’s a cost-benefit thing.

Leave A Reply