How to preserve Client Source IP with Azure Firewall, Load Balancer, and VMSS architecture?

If you are OK with a firewall other than Azure Firewall, you can use Azure Gateway Load-Balancer with Palo Alto or Fortinet firewalls and Azure Public Load-Balancer. The Gateway Load-Balancer is a bump-in-the-wire between the public IP of the Azure Public Load-Balancer and the Azure Public Load-Balancer itself. The source IP is preserved and it can handle any TCP/UDP traffic. Unfortunately, Azure Gateway Load-Balancer doesn't work with Azure firewall. https://learn.microsoft.com/en-us/azure/load-balancer/gateway-partners

Hi Subhash Chand,

let me add a few coins, when traffic passes through Azure Firewall using DNAT, the original source IP is not preserved. The firewall terminates the connection and opens a new one towards the backend. From the VMSS point of view, the client is the firewall or the load balancer, not the real user. This is how layer four NAT works and it is not configurable.

If the protocol is HTTP or HTTPS, the only correct way to preserve the client IP is to move this to layer seven. That means using Application Gateway or Front Door in front of the VMSS. These services forward the real client IP in headers such as X Forwarded For or X Original Client IP, which the application can then log and use for whitelisting.

If Azure Firewall must remain in the perimeter, the practical architecture looks like this. Client to Application Gateway to Azure Firewall to VMSS. The firewall is still used for inspection and control, while Application Gateway handles client IP preservation.

If this is not HTTP but raw TCP or UDP, then there is no solution in this design. Neither Azure Firewall nor Azure Load Balancer can preserve the source IP in this traffic path. In that case you either change the architecture or accept that the backend will never see the real client IP.

Azure Firewall with DNAT always hides the source IP. For web traffic you need a layer seven proxy. For TCP or UDP, preserving the client IP is not possible in this setup.

Rgds,

Alex

Hello @ Subhash Chand,

Thanks for reaching out to Microsoft Q&A.

You're running into a known Azure Firewall behavior related to DNAT and client IP preservation. Azure Firewall always applies SNAT to DNAT traffic, which means the backend will see the Firewall’s IP instead of the user's original public IP. Because of this design, Azure Firewall DNAT cannot be used when an application requires the real client IP for logging, auditing, or access controls.

To retain the client IP, the inbound architecture must be adjusted:

• Use Azure Application Gateway for HTTP/S: App Gateway operates as a Layer‑7 reverse proxy and passes the real client IP via the X‑Forwarded‑For header. Azure Firewall can still be used for egress or east–west inspection, just not as the inbound DNAT tier.
• For non‑HTTP workloads, use Azure Load Balancer carefully: Standard Load Balancer preserves source IP at Layer‑4, but this only works if Azure Firewall is not inline—otherwise SNAT will still override the original client IP. Separation of publishing and firewall inspection is required when client IP visibility is important.

Refer:

• Azure Firewall DNAT behavior and stateful inspection
• How Azure Application Gateway works (X‑Forwarded‑For)
• Azure Firewall FAQ (SNAT behavior)

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".