Azure firewall behind AGW

Hi Brajesh Kumar,

Welcome to Microsoft Q&A and thank you for posting your query here!

If you want to place Azure Firewall behind your Application Gateway, so that all inbound traffic first hits the Application Gateway, then passes through the Firewall, and finally reaches the spoke’s internal Application Gateway, here’s how you can achieve it:

1. Can you use Azure Firewall’s Private IP as the AGW Backend Pool?

Yes, you can, but with an important consideration.

Azure Firewall is a stateful device and is not designed to respond directly to HTTP/S health probes or host-based requests like a typical backend server. So, while you can technically add the Firewall’s private IP to the Application Gateway backend pool, it will not respond to Layer 7 health probes. This setup works best if the firewall is performing DNAT to forward traffic to downstream internal resources (like your internal AGW).

Recommendation: Use Azure Firewall DNAT rules to forward inbound traffic from the public AGW to the internal AGW’s private IP. The public AGW will send traffic to the Firewall’s private IP (backend pool entry), and the Firewall will then forward it based on DNAT configuration.

2. Health Probe for the Firewall Backend:

Since Azure Firewall won’t respond to standard health probes, your Application Gateway probe will show the backend as “unhealthy” if you probe the firewall directly.

Options:

Use a custom probe that points to a known reachable endpoint behind the firewall (e.g., a health endpoint on the internal AGW).

• Or configure the AGW to ignore probe results (not ideal but sometimes necessary in inspection-only designs).
  Refer: Create a custom probe.

3. Routing All Outbound Traffic through the Firewall:

Yes, you’ll need a User-Defined Route (UDR) on the Application Gateway subnet in the HUB to send all outbound traffic (0.0.0.0/0 or specific destination prefixes) to the Azure Firewall’s private IP as the next hop. This ensures that all egress traffic from AGW passes through the firewall for inspection.

4. Custom Route on Spoke/Internal AGW Subnet:

Yes, for return traffic, create a custom route on the internal AGW’s subnet so that response packets are also sent back out via the firewall’s private IP. This keeps both request and reply streams passing through your security controls, an important best practice for visibility and security posture

Reference guides for your setup:

• Example design and best practices: Microsoft Docs Scenario​
• Custom probe steps: Configure probes​
• Secure routing with UDRs: Routing via firewall​
• Zero trust routing example: AGW before Firewall reference​

You can place Azure Firewall behind Application Gateway using its private IP as a backend, but make sure to:

Configure DNAT rules on the firewall,

Set up a custom probe or point probes to a reachable target, and

Apply UDRs on both HUB and spoke subnets for symmetric routing.

This design ensures your inbound flows are securely inspected and properly routed through the firewall.

I hope this helps! If you need any further assistance, feel free to reach out to us.

Thanks,

Harish.

Thank you Harish.

we want use multi site listener to forward traffic to multiple project internal AGW.

Client 1-> xyz.com > Public AGW -> AzFW -> DNAT on source port 8888 translate to Internal AGW1.

Client 2-> abc.com > Public AGW -> AzFW -> DNAT on source port 8889 translate to Internal AGW2.

Hi Brajesh Kumar,

Good day, i hope you are doing grea!

Thanks for the details.

Your approach to use multi-site listeners on the Public Application Gateway (AGW) to route traffic for different domains (e.g., xyz.com, abc.com) through the Azure Firewall to separate internal Application Gateways is a solid and flexible design. Here’s how you can configure it correctly:

1. Multi-Site Listener Setup:

• On the Public Application Gateway, create multi-site listeners for each domain — for example, one for xyz.com and another for abc.com.
• Each listener should have its own HTTP setting that sends traffic to the Azure Firewall’s private IP, but on a unique destination port (e.g., 8888 for xyz.com, 8889 for abc.com).

This differentiation by destination port allows the Azure Firewall to apply specific DNAT rules for each internal AGW.

2. Azure Firewall DNAT Configuration:

In Azure Firewall, configure DNAT rules that translate based on the destination port, not the source port (since AGW uses random ephemeral source ports).

Example:

• xyz.com → AzFW Private IP:8888 if dest port = 8888 → Internal AGW1:443
• abc.com → AzFW Private IP:8889 if dest port = 8889 → Internal AGW2:443

So the flow looks like this:

Client → Public AGW (xyz.com listener)
      → Backend to AzFW Private IP:8888
          → AzFW DNAT (dest port 8888 → Internal AGW1:443)
Client → Public AGW (abc.com listener)
      → Backend to AzFW Private IP:8889
          → AzFW DNAT (dest port 8889 → Internal AGW2:443)

This ensures that traffic for each domain is properly routed through the firewall to its respective internal Application Gateway.

3. Health Probes:

Because the Azure Firewall won’t respond to HTTP probes directly:

• Configure custom health probes on the AGW that point to reachable endpoints behind the firewall (for example, /health on each internal AGW).

If end-to-end health probing is not possible, you can temporarily disable probe enforcement, though this is not recommended for production.

4. Routing and UDRs:

1. On the Public AGW subnet, create a User-Defined Route (UDR) with the next hop as the Azure Firewall’s private IP.

On each Internal AGW subnet, add a UDR to route return traffic back through the Azure Firewall. This ensures symmetric routing, which is essential for stateful inspection and proper session handling.

for more info: https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview
https://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/firewall-application-gateway

Please do let me know if you have any questions on this!

Thanks,

Harish.

Thank you very much.

Understood that we have to seperate traffic for separate destination on destination port level of DNAT rule.