Using IPsec with Exchange

Applying Front-End Policies
You have to create a new IPSec policy to force the front-end server to initiate IPSec traffic with the back-end server. This policy is easy to create because the front-end server always uses port 80 to pass traffic to the back-end server, and we know the back-end server's IP address. To create the policy, launch the IP Security Policy Management snap-in as I outlined earlier, but this time, target it toward the front-end server. Right-click the IP Security Policies On Local Machine node (the name will obviously be different if you've targeted a remote machine). Select Create IP Security Policy to launch the IP Security Policy Wizard. Proceed through the wizard, giving your new policy a meaningful name and accepting the default response rule. The real magic comes when you create a rule to secure the front-end and back-end traffic. In the wizard's last screen, make sure that you clear the Edit Properties check box before you click Finish. Under the Rules tab of the new policy's Properties dialog box, click Add to start the Security Rule Wizard. Create the rule by following these steps:

1. The Tunnel Endpoint screen is useful only if you're using IPSec in tunnel mode. This policy doesn't use tunneling, so select This rule does not specify a tunnel and click Next.
2. The Network Type screen lets you specify whether this IPSec connection applies to remote access requests, LAN traffic, or all connections. In this case, we're encrypting traffic across the LAN (or at least the portion of it in the DMZ or perimeter network), so select the Local Area Network (LAN) option before you click Next.
3. The Authentication Method screen lets you choose how the two endpoints will authenticate each other. Whenever possible, you should use Kerberos, which is the default method; it's the most secure and the easiest authentication method to administer. Select Windows 2000 Default (Kerberos V5 Protocol), and click Next.
4. The IP Filter List screen contains two default choices: All ICMP Traffic and All IP Traffic. Unfortunately, neither choice works for our situation: We want to encrypt traffic only on port 80, not all IP traffic (remember, no Kerberos over IP, and our front-end server must be able to send authentication requests to the domain controller—DC). Accordingly, you must create a new filter by clicking Add, which opens the IP Filter List dialog box.
5. Give the new filter a description and a name, then click Add to start the IP Filter Wizard. Skip the wizard's first page by clicking Next.
6. The IP Traffic Source screen of the IP Filter Wizard lets you specify the source address for the filter rule. In our case, the source for the front-end server's rule is its IP address, so make sure the Source Address drop-down list has My IP Address selected, and click Next.
7. The IP Traffic Destination screen specifies the filter rule's endpoint. The default setting matches any IP address as the destination. We want our rule to match only the IP address of the back-end server, so select A Specific IP Address from the drop-down list, then fill in the back-end server's IP address and click Next.
8. In the IP Protocol Type screen, select TCP as the protocol. If you accept the default value of Any, you can't specify the port you want to use because the rule then attempts to secure all IP traffic. You probably don't want to secure all IP traffic, particularly if your front-end server is running SMTP.
9. If you select TCP as the protocol type, the wizard opens the IP Protocol Port screen. Select the From Any Port and To This Port options, then enter "80" in the destination port field. Click Next, then click Finish.
10. When you return to the IP Filter List dialog box, click Close to return to the Security Rule Wizard. Select the IP filter list you just defined, and click Next.

In the Filter Action screen, select Require Security, then click Next. In the wizard's final screen, click Finish. Click Close on the New IP Security Policy Properties page to return to the IP Security Policy Management snap-in.

Finishing Touches
Next, you'll want to test the IPSec connection. First, check that the front-end server and back-end server can communicate; second, verify that the communication is secure. The easiest way to perform these checks is to open an IMAP or POP session to the front-end server, although opening an OWA session will also work. If you can log on to your mailbox, you know that communication is working properly. If not, the most likely culprit is either that you've specified the wrong policy on the back-end server or bobbled one of the steps for setting up the front-end-to- back-end rule. Double-check the rule settings against the steps I described earlier to ensure that all is well.

To verify that IPSec is running, you can use the Ipsecmon tool from the Microsoft Windows 2000 Server Resource Kit. Ipsecmon returns a list of active SAs; you can use this list for the front-end server and back-end server to verify that the SAs exist and that they're using the AH or ESP combination that you've specified.

Applying IPSec to your front-end/back-end communication path is simple (and, dare I say it, fun). IPSec will add a degree of security by protecting your front-end/back-end traffic against eavesdropping and tampering. However, securing the front-end-server-to-back-end-server link is only a part of your overall security strategy; you need to pay proper attention to other areas (including using SSL with OWA, proper password policies, and good patch management) to get the best possible security out of your Exchange environment. IPsec adds a small performance overhead, but the extra security is well worth it.