All requests to my App Service (Linux) appear to initiate from the same (Azure internal) IP address - WHY, and how to get the *actual* client IP addresses?

Question

I'm running Wordpress on an Azure App Service for Linux, and I noticed recently that all client requests initiate from the IP address 169.254.130.1. This - as I understand it - is an Azure-internal IP address, and is clearly not the IP address of the actual clients that are requesting pages from my site (on the order of 2000 sessions/day).

How do I update my configuration to have the actual client IP passed through to my app service? It seems that it's currently behind some sort of firewall or something? (shooting in the dark with that statement, but it's almost like my site is running behind a router on a private network)

Thanks!
Dan

Answer 1

@AdventureTaco Thank you for reaching out to Microsoft Q&A, apologize for the inconvenience caused on this.

Based on the shared information I have understood that you are trying to pull the clientIP address of client that is requesting the webapp. If yes, you can enable the diagnostic setting for your app service and query the AppServiceHTTPLogstable has the details of the CIp(clientIP) to check from which client the request is originating from.

AppServiceHTTPLogs capture the Web Server logging which contains raw HTTP request data in the W3C extended log file format. Each log message includes data such as the HTTP method, resource URI, client IP, client port, user agent, response code, and so on.

To test this behavior, I have deployed a WordPress site on linux azure app service and tried to hit the siteURL from the local machine and when I have queried the AppServiceHTTPLogs I can see my ClientIp instead of internal or azure load balancer IP as shown below.

Feel free to reach back to me if you have any further questions on this.

Answer 2

Not sure if you are still looking for a solution to this, but here goes. The Wordpress on Azure (container) app service is multi-tiered and has built-in proxy. The proxy config by default will add the headers needed to handle this scenario, as you can verify by looking at /etc/nginx/conf.d/spec-settings.conf:

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;

This however does not address the issue, but luckily, we also have Real IP module installed/running by default. With that in mind, all you need to do in order to resolve the issue is to add the following lines under the server block in your /etc/nginx/conf.d/default.conf file:

set_real_ip_from 169.254.129.0/24;
real_ip_header X-Forwarded-For;

where you might need to replace the CIDR range. Save the conf, reload nginx and you should be good to go:

And don't forget to update your startup script, as the changes will be overwritten after the container restarts.

P.S. Forgot to add the reference which helped me in troubleshooting this.

Answer 3

If you read a little bit more about TCP/IP, you will know that it is impossible to pass real client IP addresses the way you imagined. Azure, or anything similar (like reverse proxies), needs to pass real client IP addresses via extra HTTP headers (such as X-Forwarded-For) that WordPress or its extensions must extract from. Thus, if you want to find a configuration, that should be on WordPress side, not on Azure side.

Answer 4

Because azure app services are load balanced, type client ipaddress is the load balancer. Typically a load balancer will pass the client ipaddress as a header as you discovered. If you used a load balancer or firewall for your on premise iis you would have the same issue.

Also typically the client is actually behind a firewall and you get the nat translated ipaddress. With a typical isp hundreds of clients will have the same ipaddress.