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

Question

Background: I have a hub-and-spoke architecture where I am using Azure Firewall and an Azure Load Balancer to route traffic to a Virtual Machine Scale Set (VMSS). The VMSS hosts multiple web projects.

The Issue: When a user accesses a project via its URL, the backend application on the VMSS sees the Private IP address of the Azure Firewall (or Load Balancer) instead of the original Public IP of the user. This is preventing us from correctly whitelisting user IPs and logging accurate telemetry.

Current Setup:

• Ingress: Traffic hits Azure Firewall (DNAT) -> Azure Load Balancer -> VMSS.

SNAT: I have not explicitly enabled SNAT, but the firewall appears to be translating the source IP to its internal address.

Protocol: [Mention if it's HTTP/HTTPS or TCP/UDP].

Goal: I need the backend applications on the VMSS to be able to identify the original client's public IP address.

I have a hub-and-spoke architecture where I am using Azure Firewall and an Azure Load Balancer to route traffic to a Virtual Machine Scale Set (VMSS). The VMSS hosts multiple web projects.

The Issue: When a user accesses a project via its URL, the backend application on the VMSS sees the Private IP address of the Azure Firewall (or Load Balancer) instead of the original Public IP of the user. This is preventing us from correctly whitelisting user IPs and logging accurate telemetry.

Current Setup:

Ingress: Traffic hits Azure Firewall (DNAT) -> Azure Load Balancer -> VMSS.

SNAT: I have not explicitly enabled SNAT, but the firewall appears to be translating the source IP to its internal address.

Protocol: [Mention if it's HTTP/HTTPS or TCP/UDP].

Goal: I need the backend applications on the VMSS to be able to identify the original client's public IP address.

Answer 1

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

Answer 2

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".