Azure Firewall Not Working, Connectivity, Rules, and Routing Fixes

Before spending hours debugging rules, confirm your Azure Firewall actually deployed successfully and is running in a healthy state. This sounds obvious, but capacity constraints in specific zones mean your firewall might be in a degraded or failed state before you ever sent a packet through it.

In the Azure portal, go to your firewall resource and check the Status field on the Overview blade. It should read Running. If it says Failed, Stopped, or Updating, that's your first problem.

If you're in one of these regions, pay close attention to which availability zones you selected:

• East US 2 EUAP: Zone 1 and zone 4 are capacity-restricted for Basic, Standard, and Premium SKUs. You cannot deploy new firewalls there.
• North Europe: Physical zone 2 is constrained for Standard and Premium.
• South East Asia: Physical zone 3 is constrained for Standard and Premium. Critically, if you stop an existing firewall in zone 3 here, it may not restart.
• South Central US: Physical zone 3 is blocked, with availability estimated by March 31, 2026.
• West US 2: Physical zone 2 is blocked for all SKUs.
• Qatar Central: All three zones (1, 2, 3) are blocked for new deployments until December 31, 2026.
• Spain Central: Physical zone 2 is blocked until December 31, 2026.
• US Gov Virginia: Physical zone 3 is blocked for Basic and Standard, only zones 1 and 2 are available.

If you stopped a firewall in one of these constrained zones, be aware, you might not be able to start it again. The recommendation is to deploy a new firewall into an unconstrained zone or region instead of attempting to restart the stopped instance. Don't wait on this; plan your migration before you're in an emergency situation.

If everything looks healthy in the portal and your region isn't constrained, move on to step 2.

Application rules are where most Azure Firewall traffic filtering problems hide. If your outbound web traffic is dropping silently, the first thing to check is whether your application rule is configured correctly, specifically the protocol and port definition.

Open your Azure Firewall resource → Rules (classic) or your associated Firewall Policy → Application Rules. For each rule that's supposed to allow traffic:

1. Confirm the Protocol:Port field is explicitly set. A common mistake is leaving this blank when using FQDN tags, but that will cause the rule to fail silently in some configurations.
2. If you're using FQDN tags (like WindowsUpdate or MicrosoftActiveProtectionService), set the protocol value to https:443 explicitly. This is a known workaround while Microsoft works on making the port field optional for FQDN tag rules.
3. For HTTP traffic, set http:80 explicitly in the same rule or a separate rule.

For SQL FQDN filtering specifically, if you're filtering Azure SQL Database, Azure Synapse Analytics, or Azure SQL Managed Instance traffic, note that FQDN filtering via application rules only works in proxy mode. If your SQL client connects in redirect mode (which is the default for connections originating from within Azure), the application rule won't intercept the traffic correctly. You either need to force proxy mode on your SQL connection string or handle this at the network rule level.

# Check your SQL connection mode via Azure CLI
az sql server show \
  --name <your-sql-server> \
  --resource-group <your-rg> \
  --query "publicNetworkAccess"

After adjusting rules, wait 30–60 seconds for the policy to propagate, then retest connectivity. If your test VM still can't reach the target FQDN, move to step 3.

If you're using DNAT (Destination Network Address Translation) to forward inbound traffic to internal resources, there are two important constraints you need to know about.

First: DNAT on private IP addresses is only available on Standard and Premium SKUs. If you're on Basic and trying to set up a private IP DNAT rule, it simply won't work. There's no workaround at the Basic tier, you'll need to upgrade.

Second: If you have private IP DNAT rules configured and you need to deallocate your Azure Firewall for any reason (cost savings, maintenance), you'll hit a snag. The deallocation process itself fails when private DNAT rules are present. Here's the exact sequence to do it safely:

1. Go to your firewall → Rules (classic) or Firewall Policy → DNAT Rules.
2. Document all your private IP DNAT rules carefully, screenshot them or export to a text file.
3. Delete every private IP DNAT rule.
4. Deallocate the firewall via the portal or PowerShell:
   

   $azfw = Get-AzFirewall -Name "<FirewallName>" -ResourceGroupName "<RG>"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw

5. When you allocate it again, wait for the private IP to fully populate in the Overview blade before touching anything.
6. Reconfigure your DNAT rules using the newly assigned private IP address.

Also keep in mind: inbound DNAT rules always change the source IP address on return traffic. If you need to preserve the original client IP for web traffic (for logging, WAF rules, or access control), configure your backend servers or proxy layer to extract the original IP from the X-Forwarded-For (XFF) header. Azure Firewall preserves the client IP in the XFF header and appends the firewall's own IP when processing web traffic rules.

This one catches enterprise teams off guard because it looks like it should work, and the portal won't warn you that it doesn't.

If you've set up a parent firewall policy with custom DNS settings (like pointing to Azure Private DNS Resolver or a custom DNS server) and then created child policies linked to it, those child policies will not automatically inherit the parent's DNS configuration. This is a confirmed bug in Azure Firewall Policy DNS inheritance. Your child policy's rules will fail to resolve domain names correctly, which shows up as mysterious application rule failures even when the rule itself looks correct.

The workaround right now is simple but tedious: configure DNS settings directly on each child policy individually. Don't rely on parent policy DNS inheritance until Microsoft ships the fix.

To configure DNS on a child policy:

1. Go to Firewall Policies → [Child Policy Name] → DNS Settings.
2. Set DNS Proxy to Enabled if you need DNS proxy functionality.
3. Add your custom DNS server IP addresses explicitly.
4. Click Save.
5. Repeat for every child policy in your hierarchy.

While you're in DNS settings, also verify that your VNet's DNS server configuration points to the firewall's private IP (if you're using DNS proxy mode). If VMs in the spoke VNet are still using Azure's default DNS instead of routing through the firewall, FQDN-based rules won't work as expected.

# Verify DNS server config on a VNet via Azure CLI
az network vnet show \
  --name <your-vnet> \
  --resource-group <your-rg> \
  --query "dhcpOptions.dnsServers"

If this returns an empty array or the wrong IP, update your VNet DNS settings to point to the firewall's private IP address.

Two more Azure Firewall not working scenarios that are technically "working as designed" but feel completely broken in practice.

Threat intelligence alerts going silent: If you have broad network rules that allow outbound traffic on port 80 and 443 (like Allow-All-Outbound-HTTP) and you have threat intelligence mode set to Alert only, you won't see threat intelligence alerts for matching traffic. The network rule match happens first and the packet gets forwarded before the threat intel engine logs anything. This isn't a bug, it's rule priority working as designed, but it effectively silences your threat detection.

You have two fixes:

• Replace broad outbound network rules on 80/443 with explicit application rules instead. Application rules process through the threat intelligence engine before being allowed.
• Switch threat intelligence mode from Alert only to Alert and Deny, which changes the processing priority and ensures malicious destinations get blocked even when a network rule would otherwise allow the port.

To change threat intelligence mode: go to your Firewall Policy → Threat Intelligence → change the mode dropdown → Save.

ICMP and non-TCP/UDP protocols not working for internet-bound traffic: If you're trying to ping an internet host through Azure Firewall and it's failing, that's expected behavior. Network rules for non-TCP/UDP protocols (ICMP, GRE, etc.) don't work with SNAT to a public IP. The Standard Load Balancer backing Azure Firewall doesn't support SNAT for these protocol types on outbound internet traffic.

These protocols do work between spoke VNets and within private networks, just not for internet-bound traffic. Also note: if you want to configure ICMP in a network rule via PowerShell or CLI, that's another known gap, ICMP as a valid protocol is only supported through the Azure portal and the REST API today. PowerShell and CLI support is coming but not yet available.