PLEASE READ Advisory: Kernel memory issue affecting multiple OS (aka F**CKWIT, KAISER, KPTI, Meltdown & Spectre) for the latest updates.
We'd love to hear about it! Click here to go to the product suggestion community
We are about to configure NetScaler to Load balance (internally) the traffic between two clustered appliances and I wonder if anyone else did it using NetScaler or another LB solution and what recommendations would you have in regards to configuration, persistency settings etc...
We are doing this to have a site and component resilient SMTP proxy in the event of a site or appliance failure.
thanks in advance.
In general you're playing with fire and I would never recommend a load balancer for email unless your talking 10's of millions of message per day. It's simply not worth it.
A record > firewall > loadbalancer > appliance > exchange
If not done correctly you will most certainly have issues. In this scenario the load balancer does not let the mta connect to the appliance.. Instead it will replace the mta ip with its own. From the appliances perspective you will break RDNS and Filtering options. (mail from email@example.com will be delivered from 10.10.10.1) it will also prevent you from connection level blocking and delay queue will be impacted.
However if you really wish to do so..
#1 ensure your load balancer allows the mta to connect to the appliance (if this is possible then configure the rest, if not your appliance will fail to identify bad senders)
#2 configure filtering options
A: Enable policy-level blocking of mail from known bad senders (this will allow known bad hosts to relay mail instead of been dropped at connection level, it should not impact if the mail is dropped or not however ANY policy that matches may deliver the message) recommended is to drop the connection at time of connecting.
B: uncheck Enable proactive IP connection control for blocking suspicious hosts
I do NOT recommend doing this unless absolutely necessary. The BEST method for load balancing is via MX/A records each having its own ip and each pointing to its own appliance.
;; ANSWER SECTION:sophos.com. 143 IN MX 10 mx4.sophos.com.sophos.com. 143 IN MX 10 mx5.sophos.com.sophos.com. 143 IN MX 10 mx6.sophos.com.sophos.com. 143 IN MX 10 mx3.sophos.com.sophos.com. 143 IN MX 10 mx2.sophos.com.sophos.com. 143 IN MX 10 mx1.sophos.com.
;; ADDITIONAL SECTION:mx1.sophos.com. 282 IN A 184.108.40.206mx2.sophos.com. 28 IN A 220.127.116.11mx3.sophos.com. 289 IN A 18.104.22.168mx4.sophos.com. 143 IN A 22.214.171.124mx5.sophos.com. 225 IN A 126.96.36.199mx6.sophos.com. 282 IN A 188.8.131.52
every time an email is sent, its round robined through all of those addresses.. the is-spam email box probably gets 10M emails a day. Unless your talking 10's or 100's of millions of emails like o365 or gmail .. dns is the prefered method.
If you only have 1 public ip / A record.. even if you employ the worlds best load balancing for redundancy.. the second you get blacklisted, your done.
If your idea is..
A record > firewall > appliance > load balancer > exchange
In all honesty.. there is no point in devoting hardware for this, simply go into configuration / routing / mail delivery servers
click add, from the drop down select "create mail delivery group"
create 3 A records, give them all a priority of 10 and enter your downstream exchange servers.
Yeah If you are going to use a Load Balancer you must configure it to be at Layer 4 (Transport Layer) which does mean that the email appliances will need to be in their own network zone (ip range etc) with gateway pointing at the load balancer. (there are other ways but that is the easiest). For internal traffic this might be harder.
Needs to be at layer 4 as above you need to know about RDS and connection level transactions.
For internal traffic it might be ok though to simple do it at the Application layer (SMTP) but it might be a huge security risk as then you need to add the load balancers IP as a trusted relay and then any endpoint communicating via the load balancer is allowed to send email.
You really want that IP address context so you can make decisions based on it.
In reply to AlexBruce:
Thanks for the replies,
We've ended up doing it the following way,
A VIP in each site with a single SEA behind for now. (scalable)
GSLB owns the DNS record for SMTP and resolves to the primary site VIP and to the secondary in the event of a failure. (resilient)
GSLB uses a MEP to monitor the health of the SEA and failover automatically.
So from an internal perspective if a SEA fails NetScaler resolves the DNS record for SMTP to the Secondary site.
Incoming mail will use the MX records to send to either SEA and the SEA will then route it to Exchange.
This will allow internal applications that send email to external customers to have a resilient SMTP service in the event of a Site or SEA failure without human intervention.
Hope this helps someone else in the same position.
In reply to David Pereira:
Now I understand how to solve the problem, thanks.