Pass client source ip address through firewall

Hi Dee Jay Skinner,

Thanks for reaching out in Microsoft Q&A forum,

How can I setup my environment in the most cost effective way so that I can obtain this address from my VM's.

Your setup is behaving exactly as Azure Firewall is designed to: it performs Source NAT (SNAT) on inbound traffic, which replaces the original client IP with the firewall’s own IP before the request reaches your virtual machines. That’s why your applications only see the Azure Firewall IP address in their logs.

To preserve the real client source IP while still keeping your environment secure and cost‑effective, the most practical approach is to introduce an L7 (HTTP‑level) proxy in front of your VMs such as Azure Application Gateway or Azure Front Door and then read the client IP from standard HTTP headers in your application.

Use Azure Application Gateway

For most web‑application workloads, the best pattern is:

Internet > Azure Application Gateway (with WAF enabled) > Your VMs

• How it works: Application Gateway acts as a reverse proxy and automatically adds the X‑Forwarded‑For header to each HTTP request, containing the real client IP. Your application on the VM can then read this header for logging, rate limiting, geo‑blocking, or any other use case.
• Cost and security benefits:
  • Application Gateway provides WAF protection, TLS termination, and Layer 7 filtering, which often means you can reduce or eliminate the need for Azure Firewall in the inbound web traffic path.
  • You can still keep Azure Firewall for outbound traffic and internal segmentation, where it fits best.
  • Overall, this design is typically simpler and more cost‑effective than running Azure Firewall plus a separate WAF or proxy layer.

Alternative: Use Azure Front Door (for public apps)

If your applications are public‑facing and benefit from global reach:

Internet > Azure Front Door > Application Gateway or VMs

• Front Door is a global entry point that improves performance and availability.
• It injects headers such as X‑Forwarded‑For and X‑Azure-ClientIP, so your app always sees the real client IP.
• It also includes built‑in WAF and TLS termination, offloading much of the security and traffic handling from your regional resources.

Even after you adopt this architecture, your application must be configured to read the client IP from the HTTP header:

Use the X‑Forwarded‑For header as the source IP in your application or web server.

In many stacks, the first IP address in the X‑Forwarded‑For chain is the real client IP, as long as you fully control the edge (Application Gateway or Front Door).

By moving the L7 processing to Azure Application Gateway or Azure Front Door, you regain visibility of the original client IP, strengthen web‑layer security through WAF protections, and often reduce overall cost compared with keeping Azure Firewall as the primary inbound front‑end for your web traffic.

Update:

So if I have a gateway setup does that bypass the firewall for inbound traffic?

Yes, and no it depends on how you wire the traffic.

In short

• If you design your inbound path as Internet → Application Gateway → VM (with no routes sending that traffic through Azure Firewall), then inbound web traffic does bypass Azure Firewall and goes directly from the gateway to your VMs.
• If you explicitly route that traffic through Azure Firewall (for example, using User‑Defined Routes or DNAT rules), then Azure Firewall still inspects the traffic, but it will see the gateway’s IP as the source instead of the real client IP.

What this means for your setup

• Typical “cost‑effective” pattern:
  • Put Application Gateway (or Front Door) as the inbound entry point.
  • Let Application Gateway WAF handle web‑layer inspection, logging, and protections.
  • Use Azure Firewall for outbound traffic and internal segmentation, not for inbound web traffic. In this case, inbound HTTP(S) traffic bypasses Azure Firewall, but you still get security from the WAF and can read the real client IP via X‑Forwarded‑For.
• If you want Azure Firewall to inspect inbound traffic anyway:
  • Follow a pattern like: Internet → Application Gateway → Azure Firewall → VM
  • This is technically possible but more complex; Azure Firewall will see the Application Gateway’s IP, not the original client IP, unless you add something like Front Door in front to inject the X‑Forwarded‑For header early in the path.

Recommendation

For your use case (wanting the real client IP and keeping cost low), the cleanest and most common approach is:

• Use Application Gateway (with WAF) as the inbound front‑end for web apps.
• Let inbound traffic bypass Azure Firewall, and keep Azure Firewall only for outbound traffic and internal filtering.

Reference:

• Web Application Firewall features in Azure Application Gateway
• Configure IP restriction WAF rule for Azure Front Door
• Rewrite HTTP headers and URL with Application Gateway

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.