X-Forwarded-For from firewall should be sending the external IP of the incoming connection.
X-Forwarded-For is being overwritten by the firewall, so our internal servers cannot check the external IP of the incoming connection.
This is a requirement of both business logic and PCI requirements, and the firewall should be sending the external real IP instead of its own IP to the internal servers.
Correctly populating x-forwarded-for is critical frankly we pay big bucks for Azure Firewall and I have no reliable way to match IIS logs to the firewall logs. Yes most of us know we could use Azure App Gateway but that is another at least $500 per month on top of the outrageous $1000+ month Azure Firewall.
Ben Nichols commented
We have Client -> Appication Gateway -> Azure Firewall -> VM
The Application Gateway adds the X-Forwarded-For header, then the Azure Firewall should append its value to the header if it already exists. Currently it overwrites the header, so in the web server we only see the IP of the Applicate Gateway node in the X-Forwarded-For header.
Anil Inal commented
I'm also facing same issue. Client -> VNET F/W -> AGW -> VM (IIS). Especially we run e-commerce system in backend system and regulation requires client IP information. We can't keep the client ip after the traffic goes over the Azure Firewall.
Jim Keane commented
I am having the same issue. Client -> VNET F/W -> AGW -> VM (IIS). HTTP_X_FORWARDED_FOR contains only the IP:Port of the VNET F/W.
Note: this is a VNET F/W, *not* an NSG
Patrick Ghosn commented
@_JJ_ yes but it's returning the firewall IP, not the source connetion IP.