Is Azure Firewall blocking it? Finding the denied flow in the logs

#1. Does the traffic go through the firewall?

Check the effective routes on the source VM's NIC:

az network nic show-effective-route-table -g rg-app -n vm-app-01-nic -o table

You should see the destination prefix (or 0.0.0.0/0) with next hop VirtualAppliance pointing at the firewall's private IP. If the route isn't there, the firewall never sees the packet, so look at UDRs and NSGs instead.

#2. Find the deny (structured logs)

With resource-specific diagnostic tables enabled:

// Network rules (L4)
AZFWNetworkRule
| where TimeGenerated > ago(30m)
| where SourceIp == "10.20.1.4" and Action == "Deny"
| project TimeGenerated, SourceIp, DestinationIp, DestinationPort, Protocol, Policy, RuleCollection, Rule
| order by TimeGenerated desc

// Application rules (FQDN / HTTP(S))
AZFWApplicationRule
| where TimeGenerated > ago(30m)
| where SourceIp == "10.20.1.4" and Action == "Deny"
| project TimeGenerated, SourceIp, Fqdn, TargetUrl, Protocol, Rule, ActionReason

// Threat intel / IDPS hits (Premium)
union AZFWThreatIntel, AZFWIdpsSignature
| where TimeGenerated > ago(1h) and SourceIp == "10.20.1.4"

A deny with no rule name means the default deny matched: nothing allowed the flow.

#3. How rules are processed

1. DNAT rules first, then Network rules, then Application rules.
2. Within each type, by rule collection group priority, then collection priority.
3. Once a network rule matches, application rules are not evaluated for that flow.

So an "allow https to *.contoso.com" application rule never applies if a network rule already denied 443 to that destination.

#4. Write the narrow fix

• For HTTP/HTTPS to SaaS endpoints, prefer application rules with FQDNs (or FQDN tags such as WindowsUpdate).
• For non-HTTP traffic to known IPs, use network rules. Use IP Groups to keep long lists manageable.
• For FQDNs in network rules, turn on DNS proxy on the firewall and point the VNets' DNS at it, so the firewall and the clients resolve names the same way.

az network firewall policy rule-collection-group collection rule add \
  -g rg-net --policy-name fwpol-prod --rule-collection-group-name app-rcg \
  --collection-name allow-saas --name allow-api-vendor --rule-type ApplicationRule \
  --source-addresses 10.20.1.0/24 --protocols Https=443 --target-fqdns api.vendor.com

#5. Asymmetric routing

If replies come back through a different path, connections fail even though the rules look right. This is common when traffic to the spoke goes through the firewall but replies leave through a VPN or ExpressRoute route. Make sure both directions are routed through the firewall, including GatewaySubnet UDRs.

#Prevent it next time

• Keep rules in IaC and peer-review them.
• Build a workbook of top denied flows, and review it after every application change.