While working to implement Exchange 2010 support on a pair of Barracuda Load Balancer 340s I came across an issue with a counterintuitive resolution…
In this case, the Barracudas are fronting an Exchange 2010 CAS array, and a set of services was created per this documentation to support DCOM, RPC, and the GAL, as well has SSL offloading, HTTP redirection and HTTPS. Note that HTTPS was the last service created in the set. Both Outlook and OWA functioned as expected – inbound traffic to the Virtual IP (VIP) defined on the Barracudas was balanced properly across members of the CAS array. Days later additional functionality was desired – the ability to load balance inbound SMTP traffic across the CAS array – so I added an SMTP service to support that, again following this documentation. Though this service should have functioned as a simple TCP proxy, inbound SMTP traffic was immediately dropped and I contacted Barracuda to assist.
The technician explained that the Load Balancer processes services top-to-bottom, and if an issue is encountered with a particular service the services below it will not initialize properly. In this case, though Outlook and OWA were working properly, the technician found a parameter missing in the HTTPS service (HTTP Header was selected but the Header Name field was left blank, when it should have been populated with “Authorization”). This issue caused subsequent services (the SMTP service in this case) to fail. Once the parameter was entered and changes were saved SMTP began working as expected. The technician acknowledged that the GUI should do a better job of alerting users when such issues exist, and apparently that’s work in progress.
I found this interesting because one would expect services to function independently of each other. A firewall, for example, doesn’t kill unrelated rules when a single rule is invalid. In any event, I hope this info is helpful should you encounter a troublesome Barracuda in the wild.