Migration from Forefront TMG to Ironport c680

[juned.masalawala1]

Hello,

We're planning to migrate replace Microsoft Forefront TMG with Cisco Ironport c680.

I am here to get an ideas for easy and smooth migration (change over).

Need experts advise to list down the tasks before migration / change over & important things to remember.

Best Regards,

Juned

[Mathew Huynh]

Hello Juned,

All of this depends on your type of deployment, how you like things setup with your network, topology etc.

If you purchased this directly from Cisco, perhaps your Cisco Sales Engineer can assist with the setup as well or to contact Cisco PDI help.

For new deployment assistanc if you are seeking assistance with new purchased deployment, please review:-

http://www.cisco.com/web/partners/tools/pdihd.html

Else my advice.

Ensure you have corrected IP information ready.

Ensure firewall rules are updated to allow the ESA to connect outbound to internet on port 25,443,80,53 (primary ports requirement)

As for other setups or portion to add in the configuration, all of this varies depending on your requirement but we can give advice once more information is known.

Cheers

[juned.masalawala1]

Thanks Mathew for kind response.

I am new to this so need and also I do not have login for partner as of now.

Can you please share some information to ensure the IP information and basic configuration samples.

Topology would be like --> Internet--> Firewall (ASA) --> Ironport --> Mail Server

How many IP required to setup the box?

Best Regards,

Juned

[Mathew Huynh]

Standard it would be.

Port 25 SMTP -> Inbound and Outbound for mail delivery

Port 53 (TCP/UDP) DNS 

Port 80 HTTP - GUI Access (for internal) and Updates/upgrades to download from internet

Port 443 HTTPS  - (As above)

Port 22 SSH - CLI access  (And possible for tunnel)

Port 23 Telnet - CLI access 

A long list would be depending on required services:

Port Protocol In/Out Hostname Description
20/21 TCP In or Out AsyncOS IPs, FTP ServerFTP for aggregation of log files.
22 TCP In AsyncOS IPs SSH access to the CLI, aggregation of log files.
22 TCP Out SSH Server SSH aggregation of log files.
22 TCP Out SCP Server SCP Push to log server
23 Telnet In AsyncOS IPs Telnet access to the CLI, aggregation of log files.
23 Telnet Out Telnet Server Telnet upgrades, aggregation of log files 
(not recommended).
25 TCP Out Any SMTP to send email.
25 TCP In AsyncOS IPs SMTP to receive bounced email or if injecting 
email from outside firewall.
80 HTTP In AsyncOS IPs HTTP access to the GUI for system monitoring.
80 HTTP Out downloads.ironport.com Service updates, except for AsyncOS 
upgrades and McAfee definitions.
80 HTTP Out updates.ironport.com AsyncOS upgrades and McAfee Anti-Virus 
definitions.
80 HTTP Out cdn-microupdates.cloudmark.com Used for updates to 
third-party spam component in Intelligent MultiScan. Appliance must also 
connect to CIDR range 208.83.136.0/22 for third-party phone home updates.
82 HTTP In AsyncOS IPs Used for viewing the Cisco IronPort Anti-Spam 
quarantine.
83 HTTPS In AsyncOS IPs Used for viewing the Cisco IronPort Anti-Spam 
quarantine.
53 UDP/TCP In & Out DNS Servers DNS if configured to use Internet root 
servers or other DNS servers outside the firewall. Also for SenderBase 
queries.
110 TCP Out POP Server POP authentication for end users for Cisco 
IronPort Spam Quarantine
123 UDP In & Out NTP Server NTP if time servers are outside firewall.
143 TCP Out IMAP Server IMAP authentication for end users for Cisco 
IronPort Spam Quarantine
161 UDP In AsyncOS IPs SNMP Queries
162 UDP Out Management Station SNMP Traps
389 LDAP Out LDAP Servers LDAP if LDAP directory servers are outside 
firewall. LDAP authentication for Cisco IronPort Spam Quarantine
3268 LDAP Out LDAP Servers LDAP if LDAP directory servers are outside 
firewall. LDAP authentication for Cisco IronPort Spam Quarantine
636 LDAPS Out LDAPS LDAPS ActiveDirectory  Global Catalog Server
3269 LDAPS Out LDAPS LDAPS  ActiveDirectory  Global Catalog Server
443 TCP In AsyncOS IPs Secure HTTP (https) access to the GUI for system 
monitoring.
443 TCP Out res.cisco.com Cisco Registered Envelope Service
443 TCP Out updates-static.ironport.com Verify the latest files for the 
update server.
443 TCP Out phonehome.senderbase.org Receive/Send Outbreak Filters
514 UDP/TCP Out Syslog Server Syslog logging
628 TCP In AsyncOS IPs QMQP if injecting email from outside firewall.
2222 CCS In & Out AsyncOS IPs Cluster Communication Service (for 
Centralized Management).
6025 TCP Out AsyncOS IPs Cisco IronPort Spam Quarantine
7025 TCP Out AsyncOS IPs Cisco Policy Virus Outbreak Quarantine.

[juned.masalawala1]

Thanks Mathew and Ken,

Appreciate your response is very helpful.

Can also please provide some more information as below?

(1) We need to place 2 ESAs in cluster mode (inside) - assume that we will use most preferred topology as suggested by Ken.

 - Any sample configuration for above?

 - Ports configuration and IP allocations

 - any other important things to keep in mind before implementation

(2) Hardening the ESAs to be safe from internal / external threats

Thanks in advance for your kind help..!!

Best Regards,

Juned

[Paul Cardelli]

The ESA's have a ClusterConfig mode (basically configs are synced between all appliances), but not a full cluster mode as it is not really needed for email as long as your have multiple MX records configured, and setup multiple outbound connectors from your e-mail server(s).

Personally I have 2 data centers, with two ESAs at each site for one domain. We Nat the public IP for each appliance through the local firewall to the inbound port on the DMZ.

Firewall

Inbound we only allow SMTP, and maybe ICMP. This rule is to the NAT Public IP.

Outbound from the DMZ is SMTP, ICMP, and DNS (very important)

We think of Ironport ESA like a secondary firewall, but for e-mail, so we treat it like and edge network device. You can put it completely on the DMZ if you like or completely on your internal network. 

For us we have the outbound port on our internal LAN, and have our management, and email connectors as well as authentication configured to route through that interface.

Now when you configure your inbound listers make sure it is type inbound, and for your outbound listener you choose type outbound. The solution will work better this way. Think of it in the term of a firewall you would not call your WAN port (untrusted network) the same as the LAN Port (Trusted). So by ensuring the listeners are correct some of the other software features within the ESA will operate a little better, and it will avoid a few configuration mishaps as things get more complicated.

Reporting and Quarantines:

Now for reporting and Quarantines, I recommend using an SMA (now they have a virtual version). You can then hook up all your ESAs to send centralized reporting and Policy and Spam Quarantines. At this time configuration is separate, but by using ClusterConfig it is not very difficult.  There is no clustering of the SMA, but you can setup a backup SMA and schedule daily backups to the second SMA.

I hope this is helpful and I answered your questions. I also recommend reading the ESA and SMA admin guides. I believe the first few chapters talk about deployment options with diagrams.

[Ken Stieers]

Juned,

What you have drawn is a "logical" topology, not the physical one.

IP use depends on your physical topology more...

Personally, even if all 3 ports on the ESA are inside the firewall, I prefer to use at least 2 IPs: one for the "inbound" email traffic (would be NAT'd through the firewall, see Matt's email for ports.) and one for the "outbound" email traffic...   You can use the management port if you want to, but you can put those services on the "outbound" port too...

In our case, out "inbound email traffic" port is in the DMZ, we have a "management" network so the management port is there, and the "outbound" port is on our inside production network...

[Ken Stieers]

BTW, this is the email security forum, not the WEB Security forum... So Matt and I both were in Email mode...   Post your question over there.