When running on App Service the wrong client IP is reported

[derkoe]

Expected behavior

We are using the App Insights Java agent on App Service and have IP masking turned off. The expected behavior is that "request" logs should include the correct client IP in the field client_IP.

Actual behavior

The field client_IP is filled with one of the outbound IP addresses of the app service.

To Reproduce

Steps to reproduce the behavior:

• Deploy an App Service with Java 11 on Linux and App Inisights enabled
• Turn off IP masking for the App Insights
• Deploy any Spring Boot app (you can use https://github.com/derkoe/snoop) as Java JAR application
• Make some requests
• Check the field client_IP in the App Insights log type "request"

Sample Application

https://github.com/derkoe/snoop

System information

Please provide the following information:

• SDK Version: alr_java:3.0.4-BETA (auto injected by App Service, also tried manually with 3.1.1
• OS type and version: Linux
• Application Server type and version (if applicable): App Service, Spring Boot
• Using spring-boot? Yes
• Additional relevant libraries (with version, if applicable): -

Logs

applicationinsights.log
applicationinsights-extension.log

Screenshots

Additional Info

We are also running apps on Kubernetes with nginx-ingress where we get the correct address in client_IP

[derkoe]

It seems that the problem is with the "X-Forwarded-For" header. Azure App Service send the port and the IP address in this header - other load balancers and proxies only the IP address.

• Azure App Service: X-Forwarded-For: 183.13.21.23:56155
• NGINX/HAProxy: X-Forwarded-For: 183.13.21.23

The agent (or App Insights itself) cannot parse the IP:Port combination and uses the App Service IP in the logs as a fallback.

---

When I add a X-Forwarded-For to the request to the app service this IP shows up in the logs:

curl -H "X-Forwarded-For: 1.2.3.4" https://poi-snoop.azurewebsites.net/

[trask]

@derkoe great finding! we'll target this for the next release

[trask]

Submitted fix upstream, will pull in here shortly open-telemetry/opentelemetry-java-instrumentation#3651

[trask]

this should be resolved now in 3.2.0-BETA.2