Azure Front Door/Application Gateway is replacing the Client IP in X-Forwarded-For Header While Sending Data to APIM

Question

Hi,

I have a set up like Azure Front Door--> Azure Application Gateway---> Azure APIM
The logs are configured in Datadog.

For example, a request will show entry in all three services.
I can see public ip of a client (192.x.x.x) as client ip in Front Door logs.
App gateway is not yet configured for logs.
APIM logs show some private ip (10.x.x.x) as client ip.

First I thought APIM logs are showing app gateway private ip as client ip but those two ips are not matching.. only the last octate is not matching.
I dont know how app gateway is internally deployed and what ip is shown finally.

I was expecting APIM logs to show appended ips in client ip field..but it shows only 1 ip (private ip)

When I make the request via postman, I see response headers like (X-Forwarded-For : my laptop ip, same apim logs client ip)
I did not understand this as well why response headers contain X forwarded for headers.

There is so much confusion, my goal is to see public ip (shown as client ip in front door logs) as client ip in apim logs.

There is no rewrite/overwrite rules in front door or app gateway.

Please guide

Answer 1

@AmitJaiswal-8743 Thank you for reaching out to Microsoft Q&A. Based on your statement, you are making a request from Client (Laptop) -> Azure Front Door -> Application Gateway -> API Management and want to see Client IP as Laptop IP in APIM logs. Unfortunately, Client IP will not reflect the originating client, instead will return the IP address of the client from which it received the request (App Gateway here) and you cannot change it (or append to existing value).

This is where you can use "X-Forwarded-For" header to identify the originating client IP. Both Front Door and Application Gateway support X-Forwarded-For header. If the header is already present, it will append the Client IP to existing value otherwise it adds the Client IP as value. Refer Front Door and Application Gateway docs which describes about this header.

• You can rewrite this header in the application gateway as original client IP as mentioned in Remove port information from the X-Forwarded-For header. Refer a similar thread on this discussion.
  
• You can also do a filter or rewrite this header in API Management using policy and here is a sample policy.

Both will enable you to have "X-Forwarded-For" header reflecting the originating Client IP instead of appending multiple IPs. I hope this answers your question and feel free to add if you have any questions. I would be happy to assist you. Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community.

Answer 2

Hello @AmitJaiswal-8743,

I am a colleague of @MuthuKumaranMurugaachari-MSFT and I am just replying to your follow-up query here.

And these 2 private ips are not matching with the private ip shown in Azure portal--App gateway.
my app gateway is Manual scaling with only 1 instance configured. so there should be only 1 private ip in use, which is visible in Azure Portal..
Where are these 2 ips coming from ?

Just to make sure that I have understood your question correctly and if I am not wrong you are talking about the Frontend private IP address for Application Gateway on the portal as shown below.

If my understanding is correct here, then the observation above is expected. This actually due to how private IPs are used and assigned by an Application Gateway.

When an application gateway is deployed in a VNET it requires a dedicated subnet. From this subnet one private IP is assigned as Frontend private IP address and rest (apart from 5 IP addresses reserved by Azure) are used by Application Gateway instances when they scale. This information is currently documented here.

When an Application Gateway receives a request on its Frontend private IP address it routes the request to the backend server by using its instance private IP addresses. The 2 IPs that you observed above which did not match the Frontend private IP address should be from your Application Gateway's subnet which were used by its instance to communicate with the backend resource. The request flow will in the following manner.

--(Frontend private IP address)AzureAppGateway(private IP of the instance)----(privateip)AzureAPIM(privateip)-

Although you have Manual scaling setup with only one instance it is likely the private IP of the instance was changed when it scaled or due to any other update, but the instance count will not go beyond 1 in this case.

Hope this answers your question! Please let me know if you have any additional questions or concerns. Thank you!