Behind a Barracuda Web Application Firewall or Load Balancer ADC in proxy mode, IIS logs the appliance instead of your real visitors. Here's why, which of Barracuda's two options actually suits a Windows estate, and why the IIS procedure in Barracuda's own documentation no longer works on IIS 10.
Short answer. In proxy mode the Barracuda appliance terminates the client connection and opens its own to your server, so IIS records the Barracuda's WAN or LAN address in c-ip. Barracuda already sends the visitor's address in the X-Forwarded-For header by default, so nothing needs enabling on the appliance. What is missing is on the Windows side: IIS has never read that header natively. Install a filter on IIS that writes the header value into the standard c-ip field, and trust only the Barracuda's addresses.
Not every Barracuda deployment has this problem, and it is worth checking before you change anything. Barracuda's documentation for the Load Balancer ADC is explicit that for Layer 4 TCP and UDP services the real client IP is passed to the server in the TCP header, and no further configuration is necessary. If your service is Layer 4, IIS is already logging the correct address in c-ip and there is nothing to fix.
The problem applies to proxy mode: Layer 7 HTTP and HTTPS services on the Load Balancer ADC, and the Web Application Firewall, which is a reverse proxy by design. There, the appliance uses its own LAN or WAN address to reach the backend and the original client address survives only in a header.
Both the Web Application Firewall and the Load Balancer ADC document the same pair of choices, with the same trade-off:
| Option | How the server sees the client IP | Barracuda's stated cost |
|---|---|---|
| Client Impersonation | As the source IP address of the request, so IIS logs it in c-ip with no software on the server at all. |
"Requires a networking change" and a "performance impact". Every real server's default gateway must point back at the appliance, or return traffic bypasses it and the connection breaks. |
| X-Forwarded-For header (the default) | In the X-Forwarded-For request header. The source IP stays the appliance. |
"Requires a logging change." Layer 7 HTTP and HTTPS services only. |
Client Impersonation is the cleaner answer on paper, because it fixes c-ip at source. In practice it is a routing change to every backend server in the pool, it rules out any topology where those servers need a different default gateway, and Barracuda itself flags the performance cost. Most Windows estates take the second option, which is already the default: the client IP is inserted into X-Forwarded-For automatically when the request is forwarded to the backend server. That leaves exactly one thing to solve, the "logging change" Barracuda does not go into.
This is the part that catches people out. Barracuda's documented procedure for getting X-Forwarded-For into an IIS log is the article Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server, and its first step is to download and install the Microsoft Advanced Logging extension. That route is closed on a modern server, for two separate reasons:
X-Forwarded-For as a custom log field. But a custom field is a new column. c-ip keeps showing the Barracuda, and c-ip is the column your SIEM, geo-IP lookup, reporting stack and compliance parser actually read. Barracuda's IIS 7.5 procedure has the same shape: it builds a separate log definition writing to a separate file.So following the vendor documentation to the letter on Windows Server 2016 or later leaves you either unable to complete step one, or holding a second log file that none of your tooling knows about. The full detail of what the native IIS field can and cannot do is in how to log X-Forwarded-For in IIS.
Winfrasoft X-Forwarded-For for IIS is an ISAPI web filter that reads the X-Forwarded-For header the Barracuda already sends and writes the real client address into the standard IIS c-ip log field, with no application changes and no new log file. A Proxy Trust List of the Barracuda's addresses ensures only the appliance hop is trusted, so the genuine client is logged and the header cannot be spoofed.
X-Forwarded-For by default in proxy mode, so in most cases there is nothing to switch on. If someone has changed it, check the Header for Client IP Address field on BASIC > Services, and the request rewrite rule on the WAF.IISRESET, then browse the site and confirm the IIS c-ip field shows real client addresses rather than the appliance.Barracuda lets you rename the header it inserts. On the WAF the value is carried by the default request rewrite rule, and the service-level Header for Client IP Address field on BASIC > Services names the header Barracuda itself reads for the client address, with X-Forwarded-For and X-Client-IP given as the standard choices. If your estate has been set to a custom header, point the filter at that name instead. Barracuda's documentation notes that the header is customisable on all models except the Web Application Firewall 360.
When a CDN or another reverse proxy sits in front of the appliance, every request reaching Barracuda appears to come from that upstream device, and it is the upstream address that gets logged as the Client IP on BASIC > Access Logs. Barracuda's answer is to name the header the upstream proxy sets in the Header for Client IP Address field so the appliance reads through it.
The same reasoning has to be applied one hop further down, on IIS. With two proxies in the path, X-Forwarded-For arrives as a chain, and only the entries appended by hops you control are worth anything. Put both the Barracuda addresses and the upstream proxy's ranges in the Proxy Trust List so the filter walks the chain from the right and stops at the first address that is not a trusted hop. How the header chain is ordered works through this in detail.
Lock down the backend. Anything that can reach your IIS servers directly, bypassing the Barracuda, can send whatever X-Forwarded-For header it likes. Restrict the servers at the network layer so the appliance is the only path in. Trusting only the Barracuda's addresses is what makes the logged client IP reliable rather than merely present.
Yes. Both the Web Application Firewall and the Load Balancer ADC insert the client IP address into the X-Forwarded-For header by default when a request is forwarded to the backend server in proxy mode. On the WAF this is done by a request rewrite rule. There is normally nothing to enable.
Because in proxy mode the appliance terminates the client connection and opens a new one to your server, so the only address IIS sees on the connection is the Barracuda's WAN or LAN IP. The IIS c-ip field is filled from that connection, not from any header, and IIS does not read X-Forwarded-For natively in any version.
It does fix c-ip without installing anything on the server, so it is worth considering. The cost is that every real server's default gateway has to point back at the Barracuda, which constrains your network design and breaks any topology needing a different gateway, and Barracuda documents a performance impact. If that routing change is not acceptable, use the default X-Forwarded-For behaviour and solve the logging on IIS.
No. Microsoft's download page states that the Advanced Logging extension has been discontinued and is no longer available, and its readme lists IIS 7 on Windows Server 2008, 2008 R2, Vista SP1 or Windows 7 as the requirement. It was never available for IIS 10. Barracuda's article points to Enhanced Logging for IIS 8.5 as the successor, but that writes a custom column and leaves c-ip showing the appliance.
Whatever your IIS servers see as the source address of the forwarded request: the Barracuda's WAN IP for a one-arm proxy deployment or its LAN IP for a two-arm deployment, and every unit if the appliances are clustered. X-Forwarded-For for IIS then treats those as trusted hops and logs the first untrusted address, the real client.
Yes, in the sense that matters here. The filter reads X-Forwarded-For and trusts a list of addresses, so any Barracuda deployment that fronts your IIS servers as a reverse proxy and inserts the header works the same way. The only thing that changes is which source addresses you put in the Proxy Trust List.
Restore real visitor IPs in your IIS logs behind a Barracuda WAF or Load Balancer ADC. Available now for IIS 10 on Windows Server 2016–2025, with a free 14-day trial.
View the product or request a download →