Barracuda's documented procedure for logging the real client IP on IIS begins by installing a Microsoft extension that no longer exists. Here is what happens when you follow it on Windows Server 2016 or later, what the modern replacement actually does, and the part of the problem it leaves untouched.
Short answer. Barracuda's only IIS article covers IIS 7 and 7.5, and its first step is to install Microsoft Advanced Logging. Microsoft has discontinued that extension, both download links in Barracuda's article are dead, and it required IIS 7 on Windows Server 2008 in the first place. The successor Barracuda points at, Enhanced Logging, is built into IIS 8.5 and later and does let you log X-Forwarded-For. But it writes the header into a new custom column in a separate log file, and leaves c-ip still showing the Barracuda. If what you need is the standard client IP field to be correct, no native IIS feature does that.
Barracuda's guidance is consistent across the Web Application Firewall and the Load Balancer ADC. Both say the appliance inserts the client address into X-Forwarded-For by default in proxy mode, and both then hand off to a single article for the Windows side: Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server.
That article's procedure, in order, is:
X-Forwarded-For.Note what step 5 implies even on the platform it was written for: the output is a separate log definition writing to its own file, not a correction to the log IIS already writes. That distinction is the whole story on IIS 10, and it is why this page exists.
Barracuda's article closes with a single line for anything newer: to log the actual client IP address in IIS 8.5, follow Microsoft's Enhanced Logging for IIS 8.5 article. There is no IIS 10 procedure, and the pointer it gives is an http://www.iis.net/ link that now redirects to Microsoft Learn.
Both download links in Barracuda's article are dead. Following them today:
go.microsoft.com shortlink) resolves to a Bing search results page. That is what a retired Microsoft shortlink does when its target no longer exists.Microsoft is unambiguous about why. Its own download page for the extension states: "Microsoft has discontinued the Advanced Logging extension and this download is no longer available." The Advanced Logging readme on Microsoft Learn repeats the same line in place of both the download and the install instructions, and recommends Enhanced Logging for IIS 8.5 instead.
People do still find the MSI on third-party mirrors and software-archive sites. It will not help, for a reason that has nothing to do with the download being missing. The Advanced Logging readme lists the prerequisites plainly:
"You must use IIS 7 running on one of the following operating systems: Windows Server 2008, Windows Server 2008 R2, Windows Vista with SP1, Windows 7."
Asked directly on Microsoft Learn how to install Advanced Logging now that the downloads are gone, a Microsoft staff member answered: "Advanced Logging has expired, only the version before iis8 supports it." The recommended alternative given in the same answer is the built-in custom logging field, covered below.
So on Windows Server 2016, 2019, 2022 or 2025 the extension is both unavailable and unsupported. A copy retrieved from an unofficial mirror is an unsigned, unmaintained, decade-old native code module that you would be loading into every IIS worker process on a server that terminates production traffic. That is a poor trade for a logging column, and it is worth saying explicitly because the search results for "advanced logging IIS 10" are full of people trying it.
Enhanced Logging is the genuine, supported answer to the narrow question of getting a header into an IIS log, and it is free and already present. Microsoft introduced it in IIS 8.5, and its compatibility table is explicit that it was not supported before then. You do not install anything.
To add X-Forwarded-For on IIS 8.5 and later:
X-Forwarded-For (no spaces allowed), Source Type to Request Header, and Source to X-Forwarded-For. If your Barracuda has been configured to send a different header name, use that instead.Microsoft's own walkthrough uses X-FORWARDED-FOR as its worked example, so this is very much the intended use. Source Type can also be Response Header or Server Variable, and there is a quirk worth knowing: Enhanced Logging cannot log a server variable whose name contains lower-case characters.
This is the part that catches teams out after they have followed the steps and assume the job is done.
| What you get | Why it is a problem |
|---|---|
c-ip is unchanged. The custom field is an additional column. The standard client IP field keeps recording the TCP peer, which is the Barracuda. |
Every SIEM connector, geo-IP lookup, analytics import and compliance parser reads c-ip. They will all still report your appliance as the visitor. |
The log file name changes. Microsoft documents that once custom fields are configured, "IIS will create new text log files with _x appended to the file name". |
Anything ingesting logs by filename pattern can silently stop matching, or start reading two different sets of files with different schemas. This is the detail most likely to break an existing pipeline. |
| It is site-level only. Microsoft notes that if you select the server in the Connections pane, Add Field and the Custom Fields section are disabled. | On a multi-site server or a farm you configure it per site, every site, and any site added later starts without it unless somebody remembers. |
| You get the raw header. Whatever arrived, including the full chain and anything a caller forged into it, plus a 65,536 byte cap across all custom fields after which data is truncated. | The column holds an untrusted string, not an evaluated client address. Anything consuming it has to work out for itself which entry to believe, and the naive answer, the leftmost one, is the forgeable one. |
The trust point deserves emphasis because it is a security question rather than a cosmetic one. X-Forwarded-For is a chain that each hop appends to, so the reliable client address is found by reading it from the right and stopping at the first address that is not a proxy you trust. A raw column does none of that. How the header chain is ordered covers it in full.
If you only wanted the header visible for ad-hoc troubleshooting, Enhanced Logging is genuinely enough and costs nothing. Set it up and stop here.
If you needed the client IP to be right in the field your tooling already reads, the native options run out. Your realistic choices are:
c-ip at source with nothing installed on the server: the appliance connects to the backend using the client's address. Barracuda's stated costs are a networking change, a performance impact, and repointing every backend server's default gateway at the appliance. If your network design allows it, this is a legitimate answer. See the Barracuda guide for the trade-off in full.REMOTE_ADDR with URL Rewrite. Changes what the application sees, not what IIS logs, and the rules people copy from forums are easy to write in a way that silently fails for IPv6 clients.HttpContext.Connection.RemoteIpAddress. It runs inside your application, so the IIS log is written before it ever executes and c-ip is untouched.c-ip. This is the only route that makes the existing field correct, which is what makes the rest of the estate work unchanged.Winfrasoft X-Forwarded-For for IIS is an ISAPI web filter that reads the header your Barracuda already sends and writes the real client address into the standard IIS c-ip field. Nothing downstream has to change: same log file name, same W3C schema, same column your SIEM already ingests, now containing the visitor rather than the appliance.
The difference from a custom column is the Proxy Trust List. You list the addresses your IIS servers legitimately see the Barracuda arriving from, the WAN IP in a one-arm proxy deployment or the LAN IP in a two-arm one, every unit in a cluster, plus any upstream CDN ranges if something sits in front of the appliance. The filter then walks the chain from the right, skips hops you trust, and logs the first address that is not one of yours. A forged header cannot promote itself past a trusted hop, so what lands in c-ip is an evaluated address rather than a copied string. It is supported on IIS 10, Windows Server 2016 to 2025, which is precisely the range Barracuda's documentation does not cover.
You cannot. Microsoft's download page states that the Advanced Logging extension has been discontinued and the download is no longer available, and both download links in Barracuda's IIS article are dead: the Web Platform Installer gallery link lands on a generic Microsoft page and the MSI shortlink resolves to a Bing search. Copies on third-party mirrors are unsigned and unmaintained, and will not install on IIS 10 regardless.
No. Its readme requires IIS 7 on Windows Server 2008, Windows Server 2008 R2, Windows Vista SP1 or Windows 7, and a Microsoft staff answer on Microsoft Learn puts it plainly: "Advanced Logging has expired, only the version before iis8 supports it." There has never been a build for IIS 10.
Enhanced Logging, which is built into IIS 8.5 and later and needs no download. It lets you add custom W3C log fields sourced from a request header, a response header or a server variable. It covers the custom-field use case that most people wanted Advanced Logging for, but it is not a full replacement for the extension's other features and it does not change the standard c-ip field.
Only if you reconfigure it to read the new column, and only if it then evaluates the chain itself. By default the SIEM reads c-ip, which still contains the Barracuda. There is a second trap: enabling custom fields makes IIS write log files with _x appended to the name, so a collector matching the old filename pattern can quietly stop picking up new logs.
Because you selected the server rather than a site. Microsoft documents that enhanced logging is available only for site-level logging: with the server selected in the Connections pane, the Custom Fields section and the Add Field button are disabled. Select the individual site and they become available.
Usually not. Both the Web Application Firewall and the Load Balancer ADC insert X-Forwarded-For by default in proxy mode, so the header is already arriving. Check the Header for Client IP Address field on BASIC > Services only if someone has changed the header name, or if the appliance itself sits behind another proxy.
The dead-end is not. Advanced Logging was the standard advice for years, so vendor documentation, forum answers and blog posts across many load balancers still point at it. The Barracuda case is simply well documented and still live on their site. The Windows-side fix is identical whatever sits in front, only the addresses you trust change.
Write the real client IP into the standard c-ip field behind a Barracuda WAF or Load Balancer ADC, with Proxy Trust List anti-spoofing and no change to your log format or filenames. IIS 10 on Windows Server 2016–2025, with a free 14-day trial.