We sometimes hear customers talking about locating Exchange 2007 or Exchange 2010 Client Access Servers (CAS) on the perimeter network (also known as the "DMZ" - Demilitarized Zone). A perimeter network is a network zone many companies deploy between the Internet and their intranet as defense-in-depth. The idea behind a perimeter network is to add additional steps to what a hacker would have to do to get access to any intranet resources. To add as strong defense-in-depth as possible, you want to put only servers you trust to withstand Internet attacks in the perimeter, and then you should assume they can be broken into anyway.
With Exchange 2000/2003, it was supported and there was documentation explaining how to put an Exchange 2000/2003 Front-End (FE) server into the perimeter network, with a firewall between the FE and the Back-End (BE) servers it accessed. This leads some customers who upgrade from Exchange 2000/E2003 to expect the same deployment pattern with Exchange 2007/2010.
As you start planning for deploying an Exchange 2007/2010 CAS server in the perimeter network, you quickly notice that there's no documentation for how to do this though. You'll probably even find the TechNet documentation which explains this is explicitly not supported by Microsoft. Microsoft doesn't test or support any topologies which put firewalls between a CAS and a Mailbox (MBX) server. The only Exchange 2007/2010 role which is supported for deployment in a perimeter network, and with a firewall server separating it from other Exchange server it talks to, is the Edge Transport server role. This is true for Exchange servers talking to one another within and between Active Directory Sites.
The fact that there is no support for using firewalls between Exchange servers (except for the Edge Transport server role) sometimes causes confusion for how to use the Windows Server Firewall with Advanced Security on Exchange 2007/2007 servers. It's supported to have the Windows OS firewall turned on for Exchange servers. In fact, we strongly recommend you leave the Windows OS firewall turned on as a defense-in-depth measure. Exchange 2010 setup is smart enough to configure the Windows OS firewall so it'll let through all Exchange traffic appropriately. Note, for Exchange 2007 you need to run the Security Configuration Wizard and apply the Exchange 2007 role-based template. Detailed instructions can be found in Using the Security Configuration Wizard (SCW) to Secure Windows for Exchange Server Roles in Exchange 2007 docs.
When discussing the fact that it's not supported to put CAS in the perimeter network, the next question is obviously "why?". If this was supported and documented for Exchange 2000/2003 Front-End servers, why not for Exchange 2007/2010 CAS?
The most important reason why customers wanted to install Exchange FE servers in the perimeter network was to block any unauthenticated traffic from reaching servers on the intranet. This is a good practice, but as you'll see below doing this with Exchange FE/CAS servers is no longer the best way to accomplish this goal.
It is important to understand that the CAS role in Exchange 2007/2010 is significantly different from the FE server in Exchange 2000/2003.
The Exchange 2000/E2003 FE servers were there to authenticate users and proxy traffic to the BE server where the traffic was actually interpreted and responded to. For example, the FE servers in Exchange 2000/2003 don't do any Outlook Web Access (OWA) rendering. That all takes place on the BE servers. The Exchange 2007/E2010 CAS role on the other hand contains all middle-tier logic and rendering code for processes like OWA, Exchange ActiveSync (EAS), Exchange Web Services (EWS), and more.
In the same timeframe as Exchange 2007 was available, enough customers had also started using reverse proxies (e.g. Internet Security and Acceleration server (ISA) 2000 FP1, 2004 or 2006) with functionality like pre-authentication. This meant there was now a good way to do authentication of Exchange traffic before it reached the Exchange servers. The role the Exchange 2000/E2003 FE server had played for defense-in-depth by pre-authenticating traffic before it reached servers, which included a lot of Exchange business logic, could now be better handled by these new reverse proxies. The reasons a reverse proxy like this does a better job than an Exchange FE or CAS server for this defense-in-depth role are:
In addition to these reasons why a reverse proxy does a better job in the perimeter network than an Exchange FE/CAS does, there's also a problem with FE/CAS in the perimeter which goes away when using a reverse proxy there instead:
If you are curious, the ports used between server roles by E2007 are listed in Exchange Network Port Reference.
The best way to deploy Exchange CAS with respect to a perimeter network is to put a reverse proxy you trust in the perimeter, configure the firewall between the perimeter and the intranet to be as restrictive as possible and to host the CAS server on the intranet. This will get traffic inspection and other reverse proxy security filtering in place in the perimeter.As extra defense, you can also configure pre-authentication to be done on the reverse proxy. This might not be possible for all Exchange protocols if you want to expose some advanced functionality like Exchange 2010 Federated Free/Busy and Calendar Sharing to the Internet (see Understanding Federation and Understanding Federated Delegation for details about these features). But you can configure the pre-authentication for as many clients and protocols as is supported by the reverse proxy and the scenarios you want to enable.
Kristian Andaker, Jason Henderson