Hardware Load Balancing a Relay Connector

Recently I was at a customer to install an Exchange 2010 SP1 environment to upgrade their current Exchange 2003 environment. They had two DAG servers and wanted to use two Hardware Load Balancers as well. In this blog I would like to go in to the relay connectors with the HLB’s.

I’ve created two Relay Connectors, one for each Hub Transport server. Like I always do I configured the connector to only accept SMTP traffic from certain IP Addresses (Multi-Functional etc.) cause you don’t want to create an Open Relay.

Because we have HLB’s we don’t want our clients to connect directly to the Hub Transport servers. We want them to connect to the Virtual IP Address of the HLB. This means that the HLB will establish the connection to the Relay Connector.

Okay so far so good, but now you have a few options. If you have configured the HLB with the default Load Balance settings it will establish a new connection with the Relay Connector for you. This means that when a client connects to the for example relay.customer.local (the HLB Relay VIP Address) the HLB will use its own IP Address to communicate with the Relay connector. The result is that everyone can relay email through the HLB’s.

The HLB’s we used are from Barracuda and they have a nice option called “Client Impersonation”. What this option does is instead of connecting with the HLB IP Address it connects with the clients IP Address. It impersonates the client. Well that is exactly what we want.. nice I thought. But there is a problem. When you try a telnet relay.customer.local 25 you’ll get a blank screen… no HELO nothing..

I can explain what is really happening. The request is send to the HLB which then impersonates the connection to one of the Exchange servers. Exchange then sends back the information packets directly to the client. Because of the impersonation Exchange thinks the packets are coming from the client. Okay.. so now we come to the exiting part of it, the client wants to receive the packets from the HLB and doesn’t expect them to come from Exchange.

Think of it as asking a question to somebody. If I ask person B how much 2 x 2 is.  I expect him to answer me. But if person B doesn’t know the answer he will probably ask person C. When person C comes directly to me and says it’s 4 how am I supposed to know that it is the answer to my 2 x 2 question. If person C tells the answer to person B, I know that the answer belongs to my previously asked question of 2 x 2.

This means that if you set the HLB’s as the default gateway on your Exchange Servers it will work. i.e. the reply from the Exchange server will go through the load balancer and it will them pass the reply to the actual client. This will only work if the client is in a different subnet than of the exchange and barracuda, otherwise the exchange will not use the gateway IP address part. Well not in my case simply because all the IP Addresses belong to the same subnet and therefore Exchange will not use the gateway address.

So if your complete network (clients, servers, HLB’s etc.) are located on the same subnet setting the HLB as the default gateway doesn’t do the trick. In this case you’ll have to make an allow list on the HLB’s for the relay VIP Address and set the “Client Impersonation” to “No”.

Does this mean I don’t have to make an allow list on my Exchange Relay Connector? No absolutely not because you don’t want you clients to be able to connect to one of the Exchange servers directly. You’ll have to keep the Exchange and HLB’s Allow list in synch.

Special thanks to Aravind Ghosh from Barracuda support for reviewing this article.