Last Summer I wrote an article called “Firewalls Between Exchange Servers? Not On My Network!” where I addressed some of the supportability issues that come up when the network and/or security team wants to put a firewall between various components of an Exchange infrastructure. In that post, I discussed why this was unsupported, that it was a bad idea to do it anyway, and what one could expect if one went ahead and did it anyway. In short, bad things.
The Exchange Team Blog recently posted another article on the topic, and I wanted to bring it to your attention for several reasons. First, it’s by the Exchange Team-you can’t get any more authoritative than that. Second, it goes into more detail than my post did on why Microsoft has taken this stance. Finally, it states in very clear language that traffic between Exchange servers, and between Exchange servers and domain controllers, must not be restricted.
Considering the number of customers I run into each month that try to firewall off systems, this is still a chronic design issue and one that needs to be addressed. If you are an Exchange admin trying to deal with a well-meaning but overzealous security department who wants to firewall off your key systems from one another or AD, then the Exchange team has provided you with the article you need to let management overrule a bad decision.
The article in question, “Exchange, Firewalls, and Support… Oh, my!” was posted on 2013-02-18 and was authored by Brian Day, the Program Manager for the Exchange Customer Experience. Here are some key snippets from this article. I want you to read these, and focus on what they mean.
Starting with Exchange Server 2007 and current as of Exchange Server 2013, having network devices blocking ports/protocols between Exchange servers within a single organization or between Exchange servers and domain controllers in an organization is not supported.
A network device may sit in the communication path between the servers, but a rule allowing “ANY/ANY” port and protocol communication must be in place allowing free communication between Exchange servers as well as between Exchange servers and domain controllers.
The resulting increase in simplicity as well as the drop in support cases was strong enough for Microsoft to determine during the lifecycle of the next major version of Exchange Server, 2007, that we would no longer support deploying what is now the Client Access Server role in a perimeter network. From that time on all Exchange servers, except for Edge Transport Server role, were to be deployed on the intranet with unfettered access to each other.
Staying within support guidelines does in fact help us help you as expeditiously as possible, and in the end will save you time, support costs, labor costs, and last but not least aggravation.
So let’s look at each of those four points above.
Blocking ports/protocols is not supported. So that’s about as clear as it gets. If you block anything, you are not in a supported state. Why would you buy an enterprise class application for a mission critical service that every user in the company is dependent upon, and then do something that puts you in an unsupported state?
ANY/ANY Okay, network designs might require you to put a firewall between Exchange servers, or domain controllers. When you have to do that, don’t try to consult a KB article that lists all the ports and protocols that the application uses. Create a rule that allows full, unrestricted traffic between the systems. Make your firewall, at least where Exchange and AD are concerned, a router, not a filtering device. IP ANY is supported. Anything else is not.
Drop in support cases They did this because it’s better for all concerned. If you want isolation from the Internet, use an Edge Transport server in the DMZ, and publish your CAS server through TMG, UAG, or other reverse proxy.
The converse of this statement is Operating outside of support guidelines is risky, expensive, and outages will take much longer to resolve.
If you are butting heads with the security team, show them the post from the Exchange team. If they still won’t budge, take the article, print it out, and go to management. It is not security’s job to block all threats-otherwise they would just unplug everything and go home. Their job is to mitigate threats. A properly patched and deployed Exchange infrastructure is extremely secure and robust. There’s no gain in security to be had by deploying firewalls where you shouldn’t.