Azure Firewall: Intermittent Traffic Drops During DNAT Path — Investigation and Troubleshooting

Chris Machemer 0 Reputation points
2026-11-06T01:36:00.7533333+00:00

Problem description

I am experiencing intermittent connection drops on web traffic flowing from an Application Gateway through Azure Firewall to IIS backend servers via DNAT. About 10% of connections are being dropped, leading to TCP retries and page stalls. Direct connections bypassing the firewall show no issues.

Environment

Azure Firewall in East US; Application Gateway with WAF_v2 SKU; two Azure Firewall public IPs; IIS backend servers on private IPs; no route tables or NSGs attached to subnets.

What I've already tried

I ran Network Watcher Connection Troubleshoot from Application Gateway through the firewall, which showed about 10% packet drops. When testing directly to a backend server, no drops were observed. I reviewed Application Gateway metrics, which indicated increased BackendConnectTime after the incident started. I also checked firewall logs and confirmed DNAT rules were matching and allowed. No configuration changes or routing alterations were detected around the time the issue began.

Current status

I am seeking assistance to identify the root cause of the intermittent drops on the DNAT path and guidance on further diagnostics or configuration adjustments to resolve the issue.

Azure Firewall
Azure Firewall

An Azure network security service that is used to protect Azure Virtual Network resources.

0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Rukshan edirisinghe 2,365 Reputation points
    2026-11-06T02:11:31.96+00:00

    Hi @Chris Machemer

    Your tests narrow it well: the drops only happen on the path that goes through the firewall's public IPs via DNAT, and direct traffic is clean. That path is also the unusual part of the design. In Microsoft's reference architecture for Application Gateway in front of Azure Firewall, the Application Gateway sends traffic to the backends' private IPs, and a user-defined route on the Application Gateway subnet steers it to the firewall's private IP. DNAT on the public IPs is meant for traffic arriving from the internet, not for hops inside the VNet.

    So I'd check two things:

    1. Firewall health under load. In the firewall's Metrics, chart SNAT port utilization, Firewall health state and Data processed for the period when drops started. Hairpinning App Gateway traffic through public IPs adds translations on every connection, and high SNAT utilization or a degraded health state lines up with "~10% of new connections fail".
    2. Flow-level evidence. If you have the structured firewall logs in Log Analytics, enable flow trace logging. It records TCP handshake packets (SYN, ACK, RST) so you can see whether the dropped connections are reset or simply time out at the firewall.

    To fix it rather than tune around it, move to the private path:

    1. Point the App Gateway backend pool at the IIS servers' private IPs.
    2. Add a UDR on the App Gateway subnet for the backend subnet's prefix, with next hop Virtual appliance = the firewall's private IP. Add the matching UDR on the backend subnet pointing back to the firewall, so the return path is symmetric.
    3. Replace the DNAT rules with network or application rules allowing App Gateway subnet → backend on 80/443.

    Test the change on one backend first, during a quiet window.

    Did the drops start after traffic grew, or at a fixed point in time with no load change?

    If the private path clears the drops, please consider accepting it as the answer. If the metrics look clean and drops continue, let me know and I'll be happy to keep helping.

    Reference:

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.