A PPLICATION N O T E Configuring multi-burb Sendmail with load sharing High Availability This document provides the steps that are needed to configure multi-burb Sendmail in a load sharing High Availability environment. www.securecomputing.com
Table of Contents Overview... 3 Sample environment... 4 Configuring multi-burb Sendmail... 5 2 86-0945080-A
Overview Sendmail was first ported to Sidewinder for version 3.0 nearly 10 years ago. Back then, Sidewinder only provided two burbs --"internal" and "external". Therefore, we allowed the Sendmail daemons to run in these two burbs. This configuration provided a more secure SMTP pipeline through the Sidewinder, compared to the SMTP proxy, and worked well for a majority of the customers for years to come. However, not all LANs are created equal. Times changed, security issues came to the forefront of industry concerns, and the demands put on the Sidewinder quickly increased. Mail service in two burbs was just not enough for more sophisticated enterprises. Customers soon demanded "multiburb" SMTP service, allowing mail to flow to and from any number of burbs. This was accomplished using the two Sendmail daemons that are configured by default, plus adding an SMTP proxy running in the remaining burbs to allow mail to be forwarded to the one of the Sendmail daemons. Multiburb SMTP service worked well until failover and the concept of High Availability was introduced on Sidewinder G2. This document fills that gap by illustrating how to configure multiburb SMTP access on Sidewinder G2 in a load sharing High Availability (HA) environment. The discussion that follows assumes that the reader is familiar with basic Sidewinder G2 concepts and terminology including HA and load sharing. Please refer to the Sidewinder G2 Administration Guide for more information. Figure 1. Mail flowing from the DMZ mailhost to the Internet internal burb common IP address Sidewinder G2 internal burb Sendmail daemon external burb Sendmail process Internet filters SMTP proxy DMZ burb heartbeat burb DMZ mailhost DMZ burb common IP address 86-0945080-A 3
Figure 2. Mail flowing from the Internet to the DMZ mailhost Sidewinder G2 internal burb external burb Internet Sendmail process Sendmail daemon filters internal burb common IP address SMTP proxy DMZ burb heartbeat burb DMZ mailhost Sample environment This discussion on multiburb SMTP service was developed using two Sidewinder G2 firewalls at version 6.1.1.02. However, any Sidewinder G2 at version 6.1.0.02 or later will also work. Even though this discussion centers around an HA load sharing environment, multiburb SMTP service will also work on a standalone Sidewinder G2. Note: For versions prior to 6.1.1.02, the configuration process may differ. The Sidewinder G2 in this example will be configured with four network interface cards (NICs). Each NIC is assigned to its own burb, as follows: Note: Multiburb SMTP service can be scaled to accommodate more than four burbs. external burb This is the Internet burb. The Internet burb Sendmail daemon will run in this burb. internal burb This is the burb relative to your organization's "internal" LAN. The internal burb Sendmail daemon will run in this burb. dmz burb This burb will provide access to a LAN for which we require email service to and from the Internet. 4 86-0945080-A
heartbeat burb This burb and its associated NIC will serve as a conduit for HA-related communication between the Sidewinder G2s. One remote mailhost will operate relative to each burb (except for the heartbeat burb). The internal mailhost will process mail for domains in the internal LAN relative to the internal burb. The DMZ mailhost will serve the DMZ LAN relative to the dmz burb. Configuring multiburb Sendmail The following procedure provides the necessary steps for configuring multi-burb Sendmail in a load sharing HA environment. Configuration is accomplished using the Admin Console unless otherwise noted. Note: Refer to the online help for detailed information on any of the steps below. 1. Install a Sidewinder G2 in standalone mode. The Sidewinder G2 must have at least four NICs. 2. Configure four burbs (Firewall Configuration -> Burb Configuration). In this example, the four burbs are named external, internal, dmz, and heartbeat. 3. Configure each NIC, assigning a different burb to each NIC (Firewall Configuration -> Interface Configuration). 4. Configure transparent DNS (Tools -> Reconfigure DNS). Ensure that all DNS servers can perform a reverse lookup on all native firewall IP addresses as well as all cluster common IP addresses. Note: If you prefer to use Sidewinder-hosted DNS, ensure that the A records for the Sidewinder-hosted DNS servers reflect the cluster common IP address for the respective burb (and not the native IP address). 5. Configure secure split SMTP servers (Tools -> Reconfigure Mail). a. In the Internal SMTP Burb drop-down list, specify the internal burb. b. In the Internal SMTP Mail Server drop-down list, specify the internal mailhost. 6. Transition the Sidewinder G2 to HA load sharing using the State Change Wizard. To access the State Change Wizard, click the icon in the toolbar, or click on the appropriate Sidewinder G2 icon in the Admin Console tree, and click State Change Wizard. 7. Edit the M4 config file for the internal burb (Server Configuration -> Servers -> Sendmail -> Configuration. Locate the following line: DAEMON_OPTIONS(`Port=smtp, Name=MTA, M=f')dnl 86-0945080-A 5
Edit the line as follows: DAEMON_OPTIONS(`Port=smtp, Name=MTA, Addr=clusterIP, M=f')dnl where cluster_ip is the internal burb cluster common IP address. This will force the Sendmail daemon to bind only to the cluster common IP address. This allows the SMTP proxy and a Sendmail daemon to run in the same burb. 8. Create the following network objects (Policy Configuration -> Rule Elements -> Network Objects): a. Create an IP address network object for the localhost or loopback address in the internal burb. Call this object internal_burb_localhost. b. Create an IP address network object for the cluster common IP address for the internal burb. Call this object internal_common_ip. 9. Create the following proxy rules (Policy Configuration -> Rules): a. Create a proxy rule that allows client connections to both the internal burb and external burb Sendmail daemons. b. Create a DNS proxy rule to allow the internal burb to query resolvers on the Internet. Ensure that this rule does not redirect to the Sidewinder G2. Use Host:localhost for the NAT address. c. Add both rules to the active rule group. 10. Configure the internal mailhost to send all outgoing mail from this mailhost to the Sidewinder G2. That is, on the internal mailhost, specify the Sidewinder G2 s cluster common IP address for the internal burb as the mail gateway. To take advantage of load sharing, be sure to specify the cluster common IP address and not the original native NIC IP address. 11. On the external burb, ensure that the cluster common IP address is the mail exchanger for all mail domains behind the Sidewinder G2. That is, relative to the external burb on the Sidewinder G2, set up DNS so that an MX query for any domain behind the Sidewinder G2 will result in the external burb cluster common IP address. 12. Enable the SMTP proxy in the internal burb. 6 86-0945080-A
At this point, we have configured a mail pipeline between the internal and external burbs. For the scope of this document, we will also add SMTP access to the DMZ burb. In this example, we do NOT want our internal mail hosts to directly connect to remote mail servers on the Internet. Nor do we want to have Internet mail servers directly connect to our mailhosts. So, we'll let the various mailhosts talk to the Sidewinder G2's Sendmail daemons on their respective sides of the Sidewinder G2. The Sendmail daemons will in turn talk to the SMTP proxy to deliver mail from/to the DMZ mailhost. Therefore, all outgoing mail for the DMZ burb must first pass through the internal burb Sendmail daemon, which will in turn forward the mail to the external burb for subsequent delivery to its destination. All incoming mail for the DMZ burb will first pass through the external burb Sendmail daemon. This will allow us to pass the mail through various filters on the Sidewinder G2 that will perform anti-spam checking, anti-relay checking, virus checking, and so on. Configuring SMTP access for additional burbs The following steps cover burb-specific configuration. Complete the following tasks for each burb for which you require SMTP access. In the following procedure, we are configuring SMTP access for the DMZ burb. 1. If you haven t already done so, create the DMZ burb and configure one of the NICs for use in this burb. Be sure to assign the appropriate burb to the NIC. 2. Assign a cluster common IP address to the network address for the NIC (select High Availability in the Admin Console tree). 3. Create the following network objects (Policy Configuration -> Rule Elements -> Network Objects): a. Create an IP address network object for the cluster common IP address for the DMZ burb. Call this object dmz_common_ip. b. Create an IP address object for the DMZ mailhost. Call this object dmz_mailhost. 86-0945080-A 7
4. Create the following SMTP proxy rules (Policy Configuration -> Rules): a. Create a proxy rule for the SMTP proxy that allows SMTP client sessions from dmz_mailhost in the dmz burb to dmz_common_ip in the dmz burb. Do NOT specify a NAT address for this rule. For the Redirect Host, specify internal_common_ip. b. Create a proxy rule for the SMTP proxy that allows SMTP client sessions from internal_burb_localhost in the internal burb to dmz_mailhost in the dmz burb. Specify Host: localhost as a NAT address for this rule. Do NOT specify a redirect host for this rule. c. Add both rules to the active rule group. 5. Update the internal burb Sendmail configuration to reflect any new domains (Server Configuration -> Servers ->Sendmail -> Configuration). d. Edit the internal burb Access Table and add entries for any new mail domains as needed to support your mail policy. e. Edit the external burb Mailer Table and add entries for any new mail domains. In this file, you will most likely add "burbmailer" entries. For example: dmz.net burbmailer-internal:localhost.dmz.net burbmailer-internal:localhost f. Edit the internal burb Mailer Table and add entries for any new mail domains. In this file, you'll most likely add mailhost entries. For example: dmz.net esmtp:mailhost.dmz.net.dmz.net esmtp:mailhost.dmz.net 6. Configure the DMZ mailhost to send all outgoing mail to the Sidewinder G2. That is, on the DMZ mailhost, specify the dmz burb cluster common IP address as the mail gateway. 7. Enable the SMTP proxy in the dmz burb. At this point, Sendmail access between all burbs is configured. Sendmail is greatly dependent upon DNS service. Misconfigured DNS causes a majority of the Sendmail delivery problems experienced with any Sendmail environment. Double-check your DNS proxy rules for correctness and be sure the DNS proxy is enabled in the internal and dmz burbs. (Ensure that mail flows through the primary Sidewinder G2 between all burbs that require mail service before adding a second Sidewinder G2 to your HA configuration.) 8. Update syncd by adding the Sendmail configuration directory to the list of files and directories that are replicated on the HA secondary. At a 8 86-0945080-A
Sidewinder G2 command line, enter the following command: cf syncd add clone_entry path=/etc/sidewinder/ sendmail 9. Install the Sidewinder G2 that will serve as the HA secondary. Ensure the Sidewinder G2 includes the same number of NICs as the primary. In our example, the Sidewinder G2 will need four NICs. Configure the NICs and burbs to match the corresponding interface configuration on the HA primary. 10. Join the second Sidewinder G2 to the HA load sharing cluster. Remember to use the Admin Console to make any future Sendmail daemon configuration changes. Changes you make are not immediately replicated to the HA secondary Sidewinder G2. You will need to reboot the secondary Sidewinder G2 so that it will sync with the primary Sidewinder G2. 86-0945080-A 9
Product names used within are trademarks of their respective owners. Copyright 2005 Secure Computing Corporation. All rights reserved.