Got Firewalls? Read This Now.

no-firewallLast 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.

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.


  1. David Black · March 26, 2013

    I guess many security guys will get furious when they read about this novelty. A firewall might be a primitive way to protect a server or anything on a network but without it and without blocking known troublesome ports/protocols, the door is wide open to hackers to inflict the maximum damage they can. I wonder why Microsoft decided to do it, aren’t they aware of how much problems this will create, or don’t they care? Or maybe they found a clever way to cut support costs?

  2. Mary Elizabeth · March 28, 2013

    I’ve always relied on firewalls when it comes to the security of my system. Even if new protection programs started cropping up, I continued to give value to my firewall. It has kept my system safe time and again. I agree with David Black; some may perceive it as primitive, but it is one of the most effective means of network protection. To others, a firewall blocking possibly dangerous protocols may be nothing special; but for small-time business owners like me, it means a whole lot of protection and security. I hope Microsoft has something really helpful in the can.

  3. Kevin · March 29, 2013

    I agree with you, David. In fact, it’s interesting to note that some of the most effective online security methods are those that have been around for some time. Basic, yes, but they work. The “new guidelines” are going to deliver a sad and bad news to everyone who’s in charge of running a supposed reliable, convenient, and fast networking system. It’s a good thing I am no longer in that department, and I don’t have to deal with these quite conflicting rules anymore.

  4. Paul Sanders · April 3, 2013

    As they say, why fix it when it ain’t broken? When you come to think of it, the firewalls are perhaps some of the age-old technologies that have received very few updates or recognitions in recent years, but I think it’s safe to say that all of us here use them because we know they often additional protection. So it’s completely illogical to think that a company such as Microsoft would actually recommend removing them. Or perhaps they’re trying to tell us to rely in their own online security systems, which aren’t the best in the first place.

Leave A Reply