A common load balancer configuration for Exchange Server scenarios involves using source NAT.
Although some load balancing terminology differs from vendor to vendor, for the context of this article “source NAT” will refer to a configuration where the source IP address of a connection is changed from the client IP address to one of the IP addresses of the load balancer.
In this scenario the client connects to the load balancer Virtual IP address (VIP), the load balancer connects to the Exchange server, and then the Exchange server replies to the load balancer, which sends the reply back to the client.
Although there may be nothing technically wrong with this from a functionality point of view (ie, everything works for your clients without any issues), it may become a problem for you in any support situation where you need to look at IIS logs on the Exchange server. The reason this may be a problem is that the IIS logs will show a “client IP” of the load balancer, not the originating client computer or device.
For example, here the client IP of 10.1.1.9 is logged for some OAB download connections from an Outlook client, which is actually the IP address of the load balancer.
Assuming you can’t change your load balancer topology or configuration to resolve this, there are options with IIS itself that can resolve the problem instead. Two of these options are:
- Using the Advanced Logging module for IIS from Microsoft
- Using the F5XForwardedFor ISAPI filter from F5
As a side note, both of these rely on the X-Forwarded-For header being sent by the load balancer to the Exchange servers. Refer to your load balancer documentation for how to configure this option. For example, on F5 load balancers you can enable it on the HTTP profile associated with a virtual service. And on my Kemp VLM I can change the L7 configuration from default X-ClientSide to X-Forwarded-For instead.
Option 1 – Advanced Logging Module
The Advanced Logging module can be installed and configured on your Client Access servers and enables you to configure a log definition that includes the X-Forwarded-For IP address details.
This is relatively easy to do, however it means an additional set of IIS logs is being generated on your server that you’ll need to manage. It also means you’ll need to look in two sets of logs whenever you’re investigating something and need to know the client IP address. In addition, my servers were not logging the client username correctly, which is apparently a common issue. I tried this fix, but it seemed to break Advanced Logging entirely. Your mileage may vary.
Installation and configuration instructions here.
Option 2 – F5XForwaredFor ISAPI Filter
The other option I looked at is an ISAPI filter from F5. This filter looks for the X-Forwarded-For header and, if found, replaces the client IP address with the X-Forwarded-For IP address instead. Effectively this means the IIS logs contain the correct client IP address instead of the load balancer’s IP address.
This is a better approach than the Advanced Logging module from the point of view that it doesn’t require a separate set of log files to be managed. However, although it works fine in my testing (it even worked with non-F5 load balancers) I am not sure whether any support is available from F5 for the filter, though they do provide the source code.
Download and installation instructions here.
Summary
If you are running a load balancer for your Exchange Server environment and you are doing source NAT then this is an issue that you should look into sooner rather than later. It is no good to wait for a support scenario where you need to know client IP addresses and then discover that the data simply isn’t available. Instead I recommend you get ahead of the issue and implement a solution that will give you the right data when you need it.
This article Logging Client IP Address in IIS When Using Load Balancing with Source NAT is © 2014 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
