On-premises Exchange published through a hardware load balancer is one of the most common deployments we see. OWA, ActiveSync, ECP and the other virtual directories all see the connection arriving from the balancer, which breaks two different things in two different ways, and the fix for each is not the same.
Short answer. Two separate problems get lumped together here. If your IIS logs and SIEM show the load balancer's address instead of the real client, that needs a filter that writes the validated client IP into the standard c-ip field: that's what X-Forwarded-For for IIS does. If it's IP Address and Domain Restrictions that isn't behaving (blocking or allowing the wrong addresses), IIS has had a free built-in fix since IIS 8.0 called Enable Proxy Mode, and you don't need us for that one. Most Exchange estates behind a load balancer actually need both, configured separately.
A non-transparent load balancer (an F5 BIG-IP, a Citrix NetScaler, a Kemp, an Azure Application Gateway) terminates the client connection and opens its own connection to each Exchange server. As far as the IIS instances hosting OWA, ActiveSync, ECP, EWS and the rest are concerned, every request originates from the load balancer's internal address. The standard W3C c-ip field records that address for every single session, regardless of which mailbox user or device actually made the request.
That's invisible until something needs the real address. Access reporting can't tell users apart. An incident response investigation into a compromised mailbox can't identify the originating device. A compliance audit of who accessed what, from where, comes back with one address repeated for the entire estate. None of this is a bug. It's exactly how a load-balanced deployment is supposed to work at the network layer. The address just isn't in the log anymore, and Exchange doesn't restore it on its own.
Both are commonly described as "Exchange doesn't see the real client IP behind our load balancer", but they're unrelated features with unrelated fixes:
| What's actually wrong | What it affects | The fix |
|---|---|---|
| IIS logs the balancer's address | W3C c-ip field, SIEM ingestion, geo-IP, incident response, audit evidence |
A validated filter that writes the real client into c-ip — see why the standard field is the one that has to be right |
| IP Address and Domain Restrictions blocks or allows the wrong address | Access control on OWA, ActiveSync, ECP, EWS | Enable Proxy Mode (free, built into IIS since 8.0, no third-party component) |
Confusing the two leads to two failure modes: deploying an IP-restriction fix and being surprised the SIEM still shows the load balancer, or deploying a logging fix and being surprised the access-restriction rules still evaluate the wrong address. They have to be configured separately, even though both start from the same X-Forwarded-For header.
For logging, SIEM, geo-IP and compliance, the address has to land in the standard c-ip field, not a new column beside it, because that's the field every downstream tool already reads. X-Forwarded-For for IIS reads the X-Forwarded-For header the load balancer inserts, validates the chain against a Proxy Trust List so a client-supplied value can't be taken at face value, and writes the genuine address into c-ip. Nothing downstream needs reconfiguring: your SIEM connector, log shipper and compliance parser keep reading the field they already read.
If what you actually need is for IP Address and Domain Restrictions to evaluate the real client rather than the balancer — so an Allow or Deny rule targets the device that made the request, not your own infrastructure — IIS has done this since IIS 8.0, at no cost and with no third-party filter:
IIS Manager → select the site or virtual directory → IP Address and Domain Restrictions → Edit Feature Settings… in the Actions pane → tick Enable Proxy Mode. From the command line:
appcmd set config "Default Web Site" ^
-section:system.webServer/security/ipSecurity ^
/enableProxyMode:"True" /commit:apphostAdd your load balancer's addresses as an Allow entry too. Proxy Mode doesn't mean "trust the header blindly." IIS walks the X-Forwarded-For chain backwards from the end, skipping any address that's on the Allow list, and treats the first address that isn't as the client. If your balancer isn't in the Allow list, this walk never happens the way you expect and the rules keep evaluating the connecting address. The IP Address and Domain Restrictions role service also has to be installed. It isn't part of a default IIS install.
Exchange doesn't have one IIS site; it has several virtual directories, each configurable independently, and Proxy Mode set on one doesn't propagate to the others:
/owa): browser-based mail access, usually the one people test firstTreat each one as its own checklist item rather than assuming a single change at the site level covers Exchange as a whole.
Exchange Cumulative Updates have a track record of resetting IIS virtual directory configuration, including security settings applied outside the Exchange Management Shell. Re-verify Enable Proxy Mode (and any Allow-list entries) on every virtual directory after installing a CU, rather than assuming a working configuration survives the update. This is one of the more common reasons a previously-working setup "stops working" for no apparent reason after routine patching.
No. Enable Proxy Mode only changes how IP Address and Domain Restrictions evaluates the X-Forwarded-For chain for access control. It doesn't touch what gets written to the W3C c-ip field. If your SIEM, compliance reporting or incident response still needs the real client address in the logs, that's a separate fix.
The same product. Exchange's OWA, ActiveSync, ECP and EWS virtual directories are ordinary IIS sites under the hood, so X-Forwarded-For for IIS works the same way it does on any other IIS 10 workload. There's no Exchange-specific edition or configuration.
The mechanism is the same — Application Gateway inserts X-Forwarded-For the same way a hardware load balancer does. See the Azure guide for the gateway-side configuration and which Azure ranges to trust.
Cumulative Updates are known to reset IIS virtual directory settings, including Enable Proxy Mode and Allow-list entries, without warning. Re-check every Exchange virtual directory after each CU rather than assuming the configuration persisted.
X-Forwarded-For for IIS writes the validated client address into the standard c-ip field on every Exchange virtual directory, so your existing SIEM and compliance tooling needs no reconfiguration. IIS 10 on Windows Server 2016–2025, with a free 14-day trial.