Logging the real client IP in IIS behind F5 BIG-IP

Behind an F5 BIG-IP, IIS logs the load balancer's SNAT address instead of your real visitors. Here's why, and how to insert X-Forwarded-For on the BIG-IP and record the true client IP in the standard IIS log.

Short answer. A BIG-IP applies SNAT by default, so IIS sees the connection coming from the F5's SNAT or self IP and logs that in c-ip. Enable Insert X-Forwarded-For on the virtual server's HTTP profile to pass the visitor's address through, then install an ISAPI filter on IIS that reads the header and writes the real address into the standard c-ip field, trusting only your BIG-IP's SNAT addresses.

The problem

An F5 BIG-IP (LTM) sitting in front of your web servers load-balances traffic to its pool members. By default the BIG-IP applies SNAT (Secure/Source Network Address Translation), so the connection that arrives at your IIS pool member comes from the BIG-IP's SNAT or self IP, not the client. The result: the IIS c-ip log field shows the same handful of F5 addresses for every request, and geolocation, reporting and security tooling can't see the real visitor.

Why it happens

SNAT replaces the client's source address so that return traffic flows back through the BIG-IP. That's necessary for the load balancer to work, but it hides the client IP at the network layer. The fix is to carry the original client address in an HTTP header, and the BIG-IP can do exactly that:

That gets the client IP to IIS in a header. But IIS doesn't read X-Forwarded-For natively. Microsoft never added the capability, so the header arrives and is ignored. That's the gap Winfrasoft X-Forwarded-For for IIS fills.

The fix: X-Forwarded-For for IIS

Winfrasoft X-Forwarded-For for IIS is an ISAPI web filter that reads the X-Forwarded-For header the BIG-IP inserts and writes the real client address into the standard IIS c-ip log field (with no change to your applications). A Proxy Trust List of your F5 addresses ensures only the load balancer's hop is trusted, so the genuine client is logged and the header can't be spoofed.

Step by step

  1. Enable Insert X-Forwarded-For on the BIG-IP. In the HTTP profile attached to your virtual server, set Insert X-Forwarded-For to Enabled (Local Traffic → Profiles → Services → HTTP).
  2. Install X-Forwarded-For for IIS on each pool member (IIS 10 on Windows Server 2016–2025).
  3. Add the F5's source addresses to the Proxy Trust List: the SNAT addresses (or SNAT pool) and self IPs that your IIS servers actually see as the source. (See the Installation & Configuration Guide for the exact trust-list format.)
  4. Run IISRESET so the trust list takes effect, then browse the site and confirm the IIS c-ip field shows real client addresses.

Lock down the back end. So a client can't bypass the BIG-IP and forge an X-Forwarded-For header, restrict your IIS servers (firewall or IIS IP restrictions) to accept traffic only from the BIG-IP's self/SNAT addresses. Trusting only those addresses is what keeps the logged client IP reliable.

Frequently asked questions

Why does IIS log the F5 address instead of the client?

Because the BIG-IP uses SNAT, so the connection IIS receives comes from the F5's SNAT/self IP. The original client IP is only available if the BIG-IP inserts it into the X-Forwarded-For header, and IIS needs a filter to log that header.

How do I make F5 send the client IP?

Enable Insert X-Forwarded-For on the HTTP profile attached to the virtual server. The BIG-IP then adds the client's IP to the X-Forwarded-For request header on every forwarded request.

Which addresses should I add to the Proxy Trust List?

The F5 source addresses your IIS servers see: the SNAT addresses (or SNAT pool members) and self IPs. X-Forwarded-For for IIS then treats those as trusted and logs the first untrusted address, the real client.

Get X-Forwarded-For for IIS

Restore real visitor IPs in your IIS logs behind an F5 BIG-IP. Available now for IIS 10 on Windows Server 2016–2025, with a free 14-day trial.

View the product   or request a download →