Share via

Public IP Not Captured in IIS Logs – Seeing Private IP of Network Gateway Instead

Anonymous
2024-10-11T02:26:57+00:00

Hello Experts,

We are running a website on an Azure Virtual Machine (VM) with Windows Server 2022, hosted publicly via IIS. However, we've encountered an issue with the IIS logs: instead of capturing the public IP address of the end user, the logs show the private IP address of our network gateway.

Here are some key points about the setup:

  • The website is hosted on IIS in Windows Server 2022 on an Azure VM.
  • We have attempted configuring the X-Forwarded-For header in the IIS log settings, but this hasn’t resolved the issue.

Our goal is to capture the actual public IP address of the end user in the IIS logs.

Does anyone have experience resolving this issue? Could there be additional configurations needed at the Windows Server OS or IIS level to achieve this? Any guidance would be greatly appreciated.

Thanks in advance!

Windows for business | Windows Server | Windows cloud | Other

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2024-10-11T06:35:29+00:00

    Hi Saurabh Sutone,

    Thank you for posting in the Microsoft Community Forums.

    IIS Configuration

    Enable advanced logging:

    IIS's advanced logging feature allows you to customize log fields, including adding X-Forwarded-For (XFF) header information. This helps you log the original IP address after it has gone through a proxy or load balancer.

    Start IIS Manager and click on the server name on the left.

    On the home page, double-click “Advanced Logging” under “IIS”.

    Click “Enable Advanced Logging” in the right action pane.

    Click “Edit Logging Fields” to add a new field, enter “ClientSourceIP” for the Field ID, and select “Default” for the Category. “Default”, select ‘RequestHeader’ for Source type and ‘X-Forwarded-For’ for Source name. “.

    Add a log definition and select the “ClientSourceIP” field you just added.

    Apply the settings and restart IIS.

    Make sure the X-Forwarded-For header is passed correctly:

    If your site is deployed behind a load balancer or WAF appliance, you need to make sure that these devices are configured to pass the X-Forwarded-For header. This usually requires enabling X-Forwarded-For data forwarding in the device's configuration.

    Windows Server OS Configuration

    At the Windows Server OS level, you may need to ensure that IIS has permission to read and log X-Forwarded-For headers. This is usually not a required additional configuration, as the advanced logging features of IIS already provide this capability. However, if you run into permissions issues, you may need to check the permissions settings of your IIS application pool.

    Third-party plug-ins or modules

    If IIS's advanced logging features don't cut it, you can also consider using a third-party plug-in or module to log X-Forwarded-For header information. These plug-ins or modules usually offer more advanced features and customization options.

    Caution.

    Before making any configuration changes, make sure you have backed up your existing IIS configuration and log files.

    If your site uses HTTPS and you want to log information about encrypted requests in your logs, you need to make sure that your load balancer or WAF appliance supports SSL offloading or termination so that IIS can access the raw request header information.

    Monitoring and logging features may incur additional storage and performance overhead. Therefore, consider your Azure VM's storage and performance limitations when enabling these features.

    Best regards

    Neuvi

    0 comments