Behind Azure Application Gateway or Azure Front Door, IIS logs the Azure service IP instead of your real visitors. Here's why, and how to record the true client IP in the standard IIS log using the X-Forwarded-For header.
Short answer. Application Gateway and Front Door are reverse proxies, so IIS sees the connection from an Azure address (the gateway's private IP or a Front Door edge IP) and logs that in c-ip. Both services pass the visitor's address in X-Forwarded-For (Front Door also sends X-Azure-ClientIP). Install an ISAPI filter on IIS that reads the header and writes the real address into the standard c-ip field, trusting only the relevant Azure ranges.
Azure Application Gateway and Azure Front Door are reverse proxies: they terminate the client connection and open a new one to your backend. The connection your IIS backend receives comes from the Azure service — the Application Gateway's private IP, or a Front Door edge IP — so the IIS c-ip log field records Azure addresses rather than the visitor's, and geolocation, reporting and security tooling lose the real client.
This is expected for a layer-7 service. Azure preserves the original client address in HTTP headers:
X-Forwarded-For header (in ip:port form) on requests to the backend pool.X-Forwarded-For (the client IP) and also its own X-Azure-ClientIP and X-Azure-SocketIP headers.So the client IP reaches IIS in a header. But IIS doesn't read X-Forwarded-For natively. The header arrives and is ignored. That's the gap Winfrasoft X-Forwarded-For for IIS fills.
Winfrasoft X-Forwarded-For for IIS is an ISAPI web filter that reads the X-Forwarded-For header Azure adds and writes the real client address into the standard IIS c-ip log field, with no application changes. A Proxy Trust List of the Azure addresses ensures only the Azure hop is trusted, so the genuine client is logged and the header can't be spoofed.
X-Forwarded-For automatically: no switch to enable.AzureFrontDoor.Backend service tag). (See the Installation & Configuration Guide for the exact trust-list format.)IISRESET, then browse the site and confirm the IIS c-ip field shows real client addresses. Note that Application Gateway formats X-Forwarded-For as ip:port, so verify how the value lands in your logs.Lock down the backend. So a client can't reach your servers directly and forge an X-Forwarded-For header, restrict the backend's network security group to the Application Gateway subnet, or, for Front Door, to the AzureFrontDoor.Backend service tag (and validate the X-Azure-FDID header). Trusting only Azure's addresses is what keeps the logged client IP reliable.
Yes. Application Gateway adds the client's address to the X-Forwarded-For header (as ip:port) on requests to the backend pool. No configuration is required.
Front Door sends the client IP in X-Forwarded-For, and additionally in its own X-Azure-ClientIP and X-Azure-SocketIP headers. X-Forwarded-For is the cross-vendor standard and is what X-Forwarded-For for IIS reads.
For Application Gateway, the gateway subnet's private IPs. For Front Door, the Front Door backend IP ranges (the AzureFrontDoor.Backend service tag). X-Forwarded-For for IIS then logs the first untrusted address, the real client.
Restore real visitor IPs in your IIS logs behind Azure Application Gateway or Front Door. Available now for IIS 10 on Windows Server 2016–2025, with a free 14-day trial.
View the product or request a download →