A typical headache for Microsoft Exchange Server administrators is to setup load-balancing with port 25. They face the issue that, typically in these setups, they no longer see the source client IPs of the actual clients; All traffic is translated and is presented to the SMTP service with the load balancer IP as source. This makes working with receive connectors quite difficult. Many organizations have opted to use multiple virtual IPs and/or different port numbers for the SMTP service…
I think there is a better solution. I think the Direct Server Return option on load balancers provides a better solution; This option forces the load balancer to present the original client IP to the back-end server, in our case: the SMTP service of Microsoft Exchange Server. The back-end server sends response packets directly to the client instead of the load balancer (no Server Network Address Translation (NAT)).
This works fine if you have a single subnet or no firewall(s) between the client, the load balancer and the back-end server. However, if a firewall plays a role in the communications flow, then the firewall will drop the connections because of asymmetric traffic flows; The firewall notices that the TCP information does not match with what it knows.
The (not so) secret sauce
The basic trick is to have the Windows Server respond with the Virtual IP of the load balancer. This way, the TCP packet looks like it’s coming from the load balancer, but actually it’s coming from the back-end server. Most firewalls are happy and allow the traffic.
Note: The communication flow must go back and forth through the same devices. Otherwise, you still experience asymmetric traffic flow and traffic will be blocked.
Another hurdle you may encounter is the need to disable ARP responses to the actual Virtual IP addresses used by the systems. When firewalls come into play, you need to look at the communications path of the traffic. Firewalls can manipulate traffic or do additional translation, that may interfere with what you want to achieve.
How to make the actual source IP address visible to a load-balanced SMTP service
Below, I'll share the steps I follow to setup my solution.
Create a lookback adapter on Windows Server
First, we need to create a lookback adapter on the Windows Server that hosts the SMTP service. Perform the following steps with an account that has administrator privileges:
- Click Start, then type cmd in the search box.
- When cmd.exe appears, right-click it and choose Run as administrator.
The Administrator: Command Prompt window opens.
- On the command prompt, type hdwwiz.exe and press Enter.
- Click Next >.
- Select Install the hardware that I manually select from a list (Advanced):
- Click Next >:
- Select Network adapters, then click Next >:
- Select Microsoft as the manufacturer. Then, select Microsoft KM-TEST Loopback Adapter:
- Click Next >.
- Select Next > to confirm the installation:
- Click Finish to complete the installation.
Configure the Loopback adapter on Windows Server
Now, we need to configure the network adapters on the Windows Server that hosts the SMTP service. Perform the following steps with an account that has administrator privileges:
- Click Start > Control Panel > Network and Sharing Center.
- Follow the Change adapter settings link in the left navigation pane.
- Select the newly created connection and rename it to Loopback.
- Right-click the Loopback connection and choose Properties from the menu.
- Confirm that Microsoft Loopback Adapter or Microsoft Loopback Adapter # is displayed in the Connect Using: field. If it is not, return to step 2 and retry the Properties for another adapter.
- Deselect every item in the list below This connection uses the following items:, except Internet Protocol (TCP/IP):
- Select Internet Protocol (TCP/IP), and click Properties to open the Internet Protocol Version 4 (TCP/IPv4) Properties window.
- Select the Use the following IP address option.
- Fill in the IP address and Subnet mask fields of the Virtual Service that you configured on your load balancer:
- Click the Advanced… button to open the Advanced TCP/IP Settings window.
- On the IP Settings tab of the Advanced TCP/IP Settings window, deselect Automatic Metric and provide the value 254:
- Switch to the WINS tab.
- Select the Disable NetBIOS over TCP/IP option:
- Click OK to close the Advanced TCP/IP Settings window.
- Click OK to close the Internet Protocol Version 4 (TCP/IPv4) Properties window.
- Click OK to close the connection properties.
- Switch back to the Administrator: Command Prompt window.
- On the command prompt, issue the following command with the LAN interface in scope (the interface that the load balancer points to):
netsh interface ipv4 set interface "LAN" weakhostreceive=enabled
- On the command prompt, issue the following commands, too. This time, with the Loopback adapter as the target: (Repeat if you have multiple loopback interfaces)
netsh interface ipv4 set interface "loopback" weakhostsend=enabled
netsh interface ipv4 set interface "loopback" weakhostreceive=enabled
- Close the Administrator: Command Prompt window.
The configuration on the Windows Server is now complete.
Configure the load balancer and firewalls
When you have the above configuration in place on the Windows Server that hosts the SMTP service, you can enable the Direct Server Return option in your load balancer.
I personally try to implement the above solution in every project, that require me to build a new Microsoft Exchange Server environment with high-availability and load balancing. I've got the Direct Server Return option working with Citrix Netscaler and KEMP Loadmaster implementations.
Reclaim control of your SMTP configuration and regain insight to the source client IP for SMTP traffic and build secure receive connectors again, with the information above.
Test before going into production.
3 thoughts on “Field notes: Make the actual source client IP visible for a load-balanced SMTP service”
I've struggled with these mailflow config challenges for years. But personally I've come to very much dislike DSR. It adds complexity to the Exchange server that you have to account for when performing Disaster Recovery etc.. Not all admins know about the intricacies of DSR.
I prefer setting access lists on the load balancer itself rather than Exchange Receive Connectors. That has the benefit of having only one location to administer (instead of each servers receive connector). Adding an Exchange server to the environment is easier as well.
Downside is that Exchange admins not always have control over the load balancer. And you loose some logging info within Exchange logs.
However, I highly prefer the simplicity of that solution over DSR. Also, most of these connections are or should be from line-of-business applications or known devices, making logging mostly necessary for troubleshooting (i.e. If it works, you probably won't look into that logging).
Yes, it will always be a struggle to find the optimal configuration for an environment.
This is a design choice that always need to be made with cooperation with the admins of the organization itself.
@Dave, so you give the EX server a second ip and configure the relay connector on that ip?
Comments are closed.