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.
| Resource | ESA node (min / recommended) | SMA (min / recommended) |
|---|---|---|
| CPU | 4 / 8 cores | 4 / 8 cores |
| RAM | 8 / 16 GB | 16 / 32 GB |
| Disk | 200 / 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
| Purpose | Port | Direction |
|---|---|---|
| SMTP mail flow | TCP 25 | Internet to ESA, ESA to internal mail server |
| SMTPS | TCP 465 | Internet to ESA, ESA to internal mail server |
| Cluster sync and management | TCP 22 (SSH) | ESA to ESA |
| Cluster Communication Service (alternative to SSH) | TCP 2222 | ESA to ESA |
| Web management | TCP 443 | Admin to ESA / SMA |
| Log transfer | TCP 22 | ESA to SMA |
| Spam quarantine access | As configured (AsyncOS defaults to 82 / 83) | Users to SMA |
How I deploy: initial setup (each appliance)
- 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.
- Log in on the VMware console, change the default credentials immediately, and run
ifconfigto set the management interface: IP address, netmask, gateway, hostname (an FQDN such asesa01.example.local) and web GUI access. Save withcommit. - 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.
- Make sure DNS records exist for both nodes and that port 22 is open between them.
- 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.
- 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
- On each ESA, set Reporting and Message Tracking to centralised.
- 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).
- 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
| Test | Expected result |
|---|---|
| Configuration sync | A 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 SMA | The test message is visible in Message Tracking. |