ESA Behind load balancer - Any consideration?

[guibarati]

I'm deploying a cluster with 2 ESAs that will be behind a Netscaler loadbalancer to balance connections from internal users for outbound emails.

The internal users won't perform MX or any other DNS lookup. They need a single SMTP relay to connect.

Since there are a lot of internal hosts connecting a loadbalancer will be used to provide redundancy and load balancing.

The internal hosts will be forced to use TLS to talk to the ESAs for authentication.

Is there any special consideration fr the ESA configuration or the load balancer configuration to function properly with SMTP and SMTP over TLS?

Thank you!

[Libin Varghese]

Hi,

I do not see any special consideration needs to be taken for SMTP over TLS to work through the Load Balancer as long the TCP traffic over port 25 is not interrupted.

As for the ESA all connections would appear to be originating from the load balancer, you would need to add the IP address for the load balancer in the HAT Relaylist or another sendergroup with Relay action in order for those emails to be treated as outbound.

As network changes can be complex and unforeseen issues can occur it is recommended to implement it for some traffic and test for stability before making it live in production.

A useful method to test TCP test email over port 25 is using telnet from the source (such as from the load balancer.)

Using Telnet to test email (SMTP)

http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118234-technote-esa-00.html

Thank You!

Libin Varghese

[guibarati]

Thank you Libin.

Someone mentioned the possibility of doing a TLS passthrough on the load balancer and it would allow the ESA to see the internal IPs, so I'll try this approach.

Is this something you've seen before? I know this is not a loadbalancer forum, so it's more to check if you've seen it deployed.

Thank you,

[Libin Varghese]

Apologies.

Personally, I haven't.

- Libin V

[marc.luescherFRE]

Hi,

there a few more points to possibly look at :

a) a loadbalancer will always poll for the backend availability in your case the two ESA's. Make sure that your are asking the load balancer probe to poll using a SMTP probe and add the loadbalancer IP address used for this to your whitelist

b) to get the source address of the incoming SMTP hosts you will need the loadbalancer to be setup in transparent mode, only this will allow you to use inbound controls like flow control across both ESA's, otherwise you will always get the IP of the loadbalancer as source

c) monitoring, now your loadbalancer becomes critical makes sure it is monitored. A good idea would be to use an internal MX record pointing at the LB but also add ESA1 and ESA2 with higher values as a fallback.

[guibarati]

Thank you Marc

Is there any drawback on setting the load balancer in transparent mode?

[marc.luescherFRE]

Three points to mention :

a) Load Balancer in transparent mode takes less resources then the other mode

b) Since you get the source IP addresses of all senders now it is recommended to register all of them and reject anybody else using smtp on the ESAs.

c) To avoid smtp abuse I would highly recommend that you create three HAT groups and 3 associated profiles.  Name the first group like TRUSTED_INTERNAL_SYSTEMS_LOW and assign a sender profile where you allow maybe 100 messages an hour, created a second group like TRUSTED_INTERNAL_SYSTEMS_Med and assign a profile of maybe up to 500 messages an hour and one above for high volume senders. What is the purpose ? You need to protect your systems from internal applications going wild cause of too many emails or notifications. By assigning them to the three group mails will be rejected if they suddenly exceed the allocated "message allowed per hour" quota. We even go so far that we specify on a per host level if they are allowed to send to external email addresses or not.

NB Our worst day was 12'000'000 internal emails on a single day due to a corrupt SQL db.

[sdonovan123]

My company recently moved from aging hardware obscured by LBs to new VMs with LBs in a transparent most.  The LBs just redirects the source IP directly to one of the Ironports.

We use a SMTP cname to a WIP (Wide IP) in front of two LBs that redirects the traffic to one of our two datacenters.

Not having source IPs was a HUGE issue for us and this was resolved by making this move.  We have had zero issues form this and has been a major win.

[bagus.putro1]

on SMTP route 

Point your ALL DOMAIN to load ballance IP 

[marc.luescherFRE]

A few thoughts from my end.

Use case internal load balancer

set up in transparent mode

with or without port rewrite option

make sure load the balancer is not the bottleneck

make sure firewall and other access lists to load balancers include the destination IPs of the ESA's

think about a fallback since you introduce a single point of failure now

Use case external load balancer

set up in transparent mode, think about location based load balancers

make sure MX, PTR, SPF, DKIM, DMARC setup is adapted to reflect new setup

make sure load the balancer is not the bottleneck

make sure firewall and other access lists to load balancers include the destination IPs of the ESA's

think about a fallback since you introduce a single point of failure now

Using a load balancer for internal systems is very common and should not cause any issues. Using an external one needs some serious planning and testing.

I hope that helps.

-marc

[marc.luescherFRE]

A few thoughts from my end.

Use case internal load balancer

set up in transparent mode

with or without port rewrite option

make sure load the balancer is not the bottleneck

make sure firewall and other access lists to load balancers include the destination IPs of the ESA's

think about a fallback since you introduce a single point of failure now

Use case external load balancer

set up in transparent mode, think about location based load balancers

make sure MX, PTR, SPF, DKIM, DMARC setup is adapted to reflect new setup

make sure load the balancer is not the bottleneck

make sure firewall and other access lists to load balancers include the destination IPs of the ESA's

think about a fallback since you introduce a single point of failure now

Using a load balancer for internal systems is very common and should not cause any issues. Using an external one needs some serious planning and testing.

I hope that helps.

-Marc