Although the firewall rules are well documented on the web, I ran into a couple of blocks when moving the Exchange front-end server into the DMZ.  I hope in sharing what I encountered helps others find doing the same thing a little less frustrating. My instructions will be specific to my experience in doing this, and is certainly not the only way to do it.

Planning the Firewall Rules:
As I mentioned in previously there are two firewalls in this setup. One is between the Internet and the DMZ and the other is between the DMZ and the internal network. In this example both the firewalls are just the Access Control Lists ( ACLs ) on the Internet interface and the DMZ interface of a Cisco router. The the front-end server is also behind Network Address Translation ( NAT ), so the server gets assigned a local IP.

The logical layout is how to think about the set up.  Firewall 1 is actually an inbound ACL on the Gig 0/0 interface and Firewall 2 is and inbound ACL on the Gig 0/1 interface.  In this usage of inbound, ‘in’ means heading into the interface ( see the actual layout ) and not ‘inbound’ in the sense of inbound traffic from the Internet. Firewall 1 is the firewall between the front-end server and the Internet. Firewall 2 is the firewall between the front-end exchange server and the primary domain controller as well as the back-end Exchange server. The rules on Firewall 2 assume you have bound remote procedure call ( RPC ) to specific port, which I will talk about more in the section about configuring the domain controller. The rules for Firewall 1 use the public Internet IP because that is in front of the NAT, in my example the public IP is 74.125.45.100 and it gets translated to 172.16.1.2 .

Gig 0/0 ACL in ( Firewall 1 ):
permit tcp any host 74.125.45.100 eq 25
permit tcp any host 74.125.45.100 eq 80
permit tcp any host 74.125.45.100 eq 110
permit tcp any host 74.125.45.100 eq 143
permit tcp any host 74.125.45.100 eq 443
Gig 0/1 ACL in ( Firewall 2 ):
permit tcp host 172.16.1.2 host 10.10.1.51 eq 25
permit tcp host 172.16.1.2 host 10.10.1.51 eq 80
permit tcp host 172.16.1.2 host 10.10.1.51 eq 143
permit tcp host 172.16.1.2 host 10.10.1.51 eq 110
permit tcp host 172.16.1.2 host 10.10.1.51 eq 691
permit tcp host 172.16.1.2 host 10.10.1.50 eq 88
permit udp host 172.16.1.2 host 10.10.1.50 eq 88
permit tcp host 172.16.1.2 host 10.10.1.50 eq 389
permit udp host 172.16.1.2 host 10.10.1.50 eq 389
permit tcp host 172.16.1.2 host 10.10.1.50 eq 3268
permit tcp host 172.16.1.2 host 10.10.1.50 eq 53
permit udp host 172.16.1.2 host 10.10.1.50 eq 53
permit tcp host 172.16.1.2 host 10.10.1.50 eq 135
permit tcp host 172.16.1.2 host 10.10.1.50 eq 12125


Active Directory Changes:
There were three changes I had to make in Active Directory. The first was to change the DNS entries for the mail servers. The second, which took me sometime to figure out, was to add the subnet to ‘Active Directory Sites and Services’. I had to do this because this was the first Windows server being deployed in the DMZ. To do this go to Control Panel :: Administrative Tools :: Active Directory Sites and Services :: Right-Click Subnets :: New Subnet and then for our example add ‘172.16.1.1/24′ and assign to whatever site it it is in. You may also need to give it time to replicate. The third change is to bind RPC replication to a specific port so you don’t have to open the firewall between the front-end and back-end servers as much. I chose to bind it to port 12125, if you don’t do this you will have open up TCP ports 1024 and above on the firewall. To bind RPC you need two registry entires, see: http://support.microsoft.com/kb/224196

Changes on the Front End Mail Server:
Besides Assigning the new IP to the front end exchange server, you might need to bind each service to this new IP. This wasn’t apparent to me because I could still connect to the SMTP and 443 ports but I got disconnected immediately. This indicates that even though the service is set not to be listening on that IP, it does listen and just disconnects if the first packets of the session are not destined for the IP the service is bound to. I can’t image how someone at Microsoft thought that this would be a good way to design the network stack on their operating system but that seems to be the way it works. To adjust what IP webmail (ports 80 and 443) are bound to, go to: Control Panel :: Administrative Tools :: Internet Information Services ( IIS ) Manager :: Local Computer :: Web Sites :: Right Click which ever web sites is for web mail :: Web Site Tab and then change the IP to whatever the new IP is for your front-end server, in our example, 172.16.1.2. Then to change the SMTP port and other service are bound to, go to: Exchange System Manager :: Administrative Groups :: Your Administrative Group ( i.e. First Administrative Group ) :: Servers :: The Front-End Server :: Protocols and then expanded each protocol, right click the virtual server, and change the IP in the General Tab.

Changes on the Back End Mail Server:
When I did this I did not have to make any changes to the back end server, but you can check the references section for things you may need to do. Also, this is windows, so you should probably reboot the server for good measure, and maybe several times.

Conclusion:
Although your experience may be different I hope this helps people trying to do a similar thing.

References:
http://technet.microsoft.com/en-us/library/aa997436(EXCHG.65).aspx
http://windowsitpro.com/article/articleid/46571/what-ports-do-you-need-to-open-to-allow-communication-between-a-microsoft-exchange-server-back-end-server-and-an-exchange-front-end-server.html