back
~/articles/networking/cisco-esa-and-sma-clustering-design-and-rollout-notes

Cisco ESA and SMA clustering: design and rollout notes

Cisco Secure Email Gateway (still widely called ESA, the Email Security Appliance) is the front line against phishing, spam, malware and business email compromise. The Security Management Appliance (SMA) adds centralised reporting, message tracking and quarantine across several ESAs. These are my notes on building the pair as a clustered, highly available design, from high-level design down to configuration.

Why I design it this way

  • Clustering: configuration is synchronised between the ESA nodes for redundancy and single-point management.
  • High availability: mail is distributed across the cluster nodes using MX records.
  • Centralised tracking: every message can be traced from one SMA console without logging in to each appliance.

Architecture

Two or more ESAs sit at the network edge and process mail. One SMA sits on the out-of-band management network, collects logs and manages the quarantine.

Internet
   |            |
[Firewall]   [Firewall]
   |            |
+------------+  +------------+
| ESA Node 1 |<->| ESA Node 2 |   cluster / config sync
+------------+  +------------+
        |            |
        +-----+------+
              |  logs and quarantine data
              v
   SMA (centralised management)
              ^
        admin console

How I size it

I normally deploy these as virtual appliances on VMware ESXi, using the C600V model for ESA and the M600V model for SMA.

ResourceESA node (min / recommended)SMA (min / recommended)
CPU4 / 8 cores4 / 8 cores
RAM8 / 16 GB16 / 32 GB
Disk200 / 500 GB (thin)500 GB / 1 TB+

More CPU helps the antivirus and anti-spam engines. More RAM speeds up the mail queue on the ESA and the log database on the SMA. On the SMA, disk space is the critical resource because it holds logs and quarantine.

Network and ports

PurposePortDirection
SMTP mail flowTCP 25Internet to ESA, ESA to internal mail server
SMTPSTCP 465Internet to ESA, ESA to internal mail server
Cluster sync and managementTCP 22 (SSH)ESA to ESA
Cluster Communication Service (alternative to SSH)TCP 2222ESA to ESA
Web managementTCP 443Admin to ESA / SMA
Log transferTCP 22ESA to SMA
Spam quarantine accessAs configured (AsyncOS defaults to 82 / 83)Users to SMA

How I deploy: initial setup (each appliance)

  1. Deploy the OVF on ESXi and connect the first network card (management) and the second (data) to the right VLANs, then power on the VM.
  2. Log in on the VMware console, change the default credentials immediately, and run ifconfig to set the management interface: IP address, netmask, gateway, hostname (an FQDN such as esa01.example.local) and web GUI access. Save with commit.
  3. Repeat for the second ESA and the SMA, then open the GUI at the address you assigned.

What I configure in the GUI

  • System Setup Wizard: gateway, DNS, domain, password, listener and LDAP basics.
  • Updates: if the appliances have no direct internet access, point them at an approved proxy under Security Services → Service Updates so engines and rules can update.
  • Licensing: ESA licensing is token-based through Smart Software Licensing. Set the appliance to use a Transport Gateway under System Administration → Smart Software Licensing, register it with your token, then request every licensed feature until the status shows "In Compliance". Then enable the features.
  • HAT (Host Access Table): controls sender reputation and ties into Cisco Talos. Add your own domain to the trusted sender group that has the relay policy.
  • RAT (Recipient Access Table): stops the ESA from accepting mail for domains that are not yours. Add your domains under Mail Policies → Recipient Access Table.
  • TLS: import the certificate in PKCS#12 format under Network → Certificates, then select it for outgoing mail (Destination Controls) and for incoming mail in every sender group's mail flow policy.
  • SPF, DKIM and DMARC: import the DKIM signing key under Mail Policies → Signing Keys, then enable SPF, DKIM and DMARC checks in the mail flow policies of all sender groups.
  • Exchange: create a Send Connector and a Receive Connector so that the ESA's address is the smart host.
  • Content filtering: incoming and outgoing content filters under Mail Policies let you act on mail according to your own rules.

How I create the cluster

The goal is a single management group so that a change made on one node is applied on the other.

  1. Make sure DNS records exist for both nodes and that port 22 is open between them.
  2. On node 1, give the IP interfaces the same names on both appliances (for example Management and Data1), then go to System Administration → Cluster, choose Create Cluster, name it (for example Main_Cluster), pick SSH or CCS as the transport (SSH is the more common choice) and select the management interface.
  3. On node 2, go to System Administration → Cluster, choose "Join an existing cluster over SSH", enter node 1's IP address and administrator credentials. Policies, dictionaries and the rest of the configuration then replicate from node 1.

Connecting to the SMA

  1. On each ESA, set Reporting and Message Tracking to centralised.
  2. On the SMA, go to Management Appliance → Centralized Services → Security Appliances, choose Add Email Appliance, enter the name and IP address of each ESA and click Establish Connection (SSH is required).
  3. For each ESA, enable Centralized Reporting, Centralized Message Tracking and Spam Quarantine so that spam is stored on the SMA disk.

How I test before handover

TestExpected result
Configuration syncA test policy created on node 1 appears on node 2.
Mail delivery (Telnet to port 25)A test message is accepted by both nodes.
Log check on the SMAThe test message is visible in Message Tracking.
Article Type