How to stop sending origin IP with Azure Api Management Gateway

Question

I'm fiddling a bit with Azure API Management Gateway to see if it would fit our purpose. It was quite simple to add an API from our ERP application (Saas app with IP whitelisting our Office locations) and I'm able to call it from within our office. However, when I call the api from any other location, I get the message from the ERP that the IP is blocked. I'm currently on a Development tier and (should) have a static IP assigned let's say

VIP public: 20.82.86.xxx

What I've done so far:

• added a inboud policy, stripping the x-forwarded-for header, tried both API level and operation level

   <inbound>
   <base />
   <set-header name="X-Forwarded-For" exists-action="delete" />
  

What I've tested/noticed so far:

• When I test the call from within APIM, the IP is blocked. I can see that the header is stripped on inbound set-header (0.008 ms) "Header X-Forwarded-For was removed."
• I see that APIM is adding a x-forwarded-for header in backend, seems with the IP of the frontend/APIM website {"name": "X-Forwarded-For","value": "13.91.254.xxx"}
• The response I get back is that the ip from my device (84.105.xxx.xxx) is blocked by the ERP

I don't understand why the originating IP is the local IP from my device/location instead of the API Gateway.

Azure API Managemnent gateway seems to be very useful for our purpose and it's not that difficult the work with. However it's important that I can call it from other locations than our office. Any ideas?

Answer 1

If you have added any such header exclusively before forwarding the request to the backend via policy, it can be removed via policy. But the X-Forwarded-For header being added by the APIM gateway by default cannot be eliminated since this is by design and is required by the service to accurately forward the request to the backend API.

https://www.geeksforgeeks.org/http-headers-x-forwarded-for/

Answer 2

I tested setting an explicit value for the X-Forwarded-For header like this in the inbound policy:

    <set-header name="X-Forwarded-For" exists-action="override">
        <value>xx.xx.xx.xx</value>
    </set-header> 

Then the resulting header in the backend request was:

X-Forwarded-For: xx.xx.xx.xx,yy.yy.yy.yy

This might fool your backend to think that xx.xx.xx.xx is your client IP, when it is really yy.yy.yy.yy.