The Internet Information Services (IIS) running behind Azure Application Gateway have no direct way of finding out the real public IP address of the client sending the request. Well that may not be true because in the App itself, you may be able to catch the X-Forwarded-For header and use it.

But W3C Logging format cannot capture this header!

The problem comes when you want to capture this information in the W3C Logging Fields, which does not support direct mapping for any header named X-Forwarded-For.

The workaround to capture Client IP coming from Azure Application Gateway in IIS W3C Logs

Because we know that our IIS is receiving traffic from Azure Application Gateway, and we know that the true client IP is not of the Application Gateway itself but the one in the request header of X-Forwarded-For coming from App Gateway, what we can do is to swap the mapping of the c-ip field with that of X-Forwarded-For

We are essentially changing this field

By over-writing it with this one

What this will lead to is that all that the X-Forwarded-For header coming from App Gateway will be logged into the standard W3C log fields, instead of using any extension number of fields.

But why I could use this in W3C Extended logs?

The idea is to discourage extended fields as they are not captured by many downstream systems, for example agent running in VM having IIS in Azure will not transport extended fields to the Log Analytics workspace! By using the above solution, we ensure that the correct logs are transported and are made available to the Log Analytics workspace.