Azure Firewall Not Working? Fix Setup & Config Errors
Why This Is Happening
You deployed Azure Firewall, everything looked fine in the portal , green checkmarks, no errors , and then your workloads stopped reaching the internet. Or maybe traffic that should be blocked is sailing right through. Or you're staring at a connectivity timeout and have no idea which rule is the culprit. I've seen this exact scenario dozens of times across enterprise Azure environments, and I'll tell you what's actually going on.
Azure Firewall is a fully stateful, cloud-native network security service that inspects both east-west traffic (between internal Azure resources) and north-south traffic (between your Azure environment and the internet or on-premises networks). That sounds clean on paper. In practice, it means there are multiple layers where things can go wrong, and Microsoft's error messages rarely point you directly at the real cause.
The most common reasons Azure Firewall stops working or misbehaves fall into a few categories. First, SKU mismatch: teams deploy Azure Firewall Basic when their workload actually needs Standard or Premium features. Basic is designed for small and medium-sized businesses with an estimated throughput ceiling of 250 Mbps and only supports Threat Intelligence in alert mode, it won't block traffic based on threat intel. If you're expecting active blocking of malicious IP addresses and domains, you need Standard or Premium. Discovering this after deployment is a painful surprise.
Second, rule processing order confusion. Azure Firewall applies rules in a specific priority sequence, NAT rules, then network rules, then application rules. A lot of misconfiguration happens when engineers assume application rules override network rules, or vice versa. A deny rule at the wrong level silently drops traffic without telling you why.
Third, DNS resolution failures. If you've enabled Azure Firewall's DNS proxy feature (available in Standard and Premium SKUs) but haven't pointed your virtual machines' DNS settings at the firewall's private IP address, FQDN-based rules simply won't resolve correctly. The firewall can't match traffic against a domain name it never looked up.
Fourth, SNAT and routing problems. For the firewall to inspect outbound traffic, your User Defined Routes (UDRs) must send traffic through the firewall. If those routes are missing, misconfigured, or overridden by BGP routes from an ExpressRoute or VPN gateway, traffic bypasses the firewall entirely, and you'll never see it in the logs.
These issues affect everyone from solo developers setting up their first Azure environment to enterprise network architects managing hundreds of subscriptions via Azure Firewall Manager. The good news: every one of these problems has a clear fix. Let's work through them.
Browse all Microsoft fix guides →The Quick Fix, Try This First
Before spending an hour chasing logs, do this one check first: open the Azure portal, navigate to your Azure Firewall resource, click Logs in the left menu, and run a quick query against the AzureDiagnostics table. Specifically, look for the AzureFirewallNetworkRule and AzureFirewallApplicationRule log categories. If you see entries with Action_s: "Deny", you've found your problem in under two minutes.
Here's the exact Kusto query to paste into Log Analytics:
AzureDiagnostics
| where Category == "AzureFirewallNetworkRule" or Category == "AzureFirewallApplicationRule"
| where TimeGenerated > ago(1h)
| where msg_s contains "Deny" or msg_s contains "DENY"
| project TimeGenerated, Category, msg_s, Protocol_s, SourceIP_s, DestinationIP_s, DestinationPort_d
| order by TimeGenerated desc
| take 50This query scans the last hour of firewall logs for denied traffic. It will show you the exact source IP, destination IP, port, and protocol that was blocked. Nine times out of ten, this single query tells you exactly which rule is causing the problem, whether it's a missing application rule for a specific FQDN, or a network rule gap for a port your application needs open.
If you don't see any logs at all, that's its own problem: diagnostic settings aren't configured. Go to your Azure Firewall resource → Diagnostic settings → Add diagnostic setting. Enable AzureFirewallApplicationRule, AzureFirewallNetworkRule, and AzureFirewallDnsProxy log categories and send them to a Log Analytics workspace. Without this, you're flying completely blind.
Once diagnostic logging is flowing, re-run the query above. If you see denied traffic matching your problem symptoms, skip ahead to Step 3 to fix the specific rule. If logs show allowed traffic but connectivity still fails, the issue is likely routing, go to Step 4.
This is the step most engineers skip, and it causes headaches for months. Azure Firewall comes in three SKUs, Basic, Standard, and Premium, and they are not interchangeable. Choosing the wrong one means features you're counting on simply don't exist in your deployment.
Azure Firewall Basic is affordable and fine for straightforward SMB scenarios, but it has hard limits: throughput caps at 250 Mbps, it runs on a fixed scale unit with exactly two virtual machine backend instances, and threat intelligence only fires in alert mode. That last point matters a lot. Basic will log a warning when traffic matches a known malicious IP or domain, but it will not block it. If you need blocking, you need Standard or Premium.
Azure Firewall Standard gives you active threat intelligence-based filtering, both alert and deny, along with full L3–L7 filtering, network-level FQDN filtering across all ports and protocols, web content filtering via web categories, DNS proxy with custom DNS support, auto-scaling up to 30 Gbps, and fat flow support up to 1 Gbps. This covers the vast majority of enterprise workloads.
Azure Firewall Premium adds signature-based IDPS (Intrusion Detection and Prevention System) with over 67,000 signatures across more than 50 categories, updated in real time. It also adds URL filtering with full path inspection (including SSL termination), outbound TLS termination acting as a TLS forward proxy, auto-scaling up to 100 Gbps, and fat flow support up to 10 Gbps. If you're running financial services, healthcare, or any workload touching PCI DSS compliance, Premium is the right tier.
To check your current SKU in the portal: go to your Azure Firewall resource → Overview → look for the SKU field in the essentials pane. If you need to upgrade, you can change the SKU through Azure PowerShell:
$azfw = Get-AzFirewall -Name "MyFirewall" -ResourceGroupName "MyResourceGroup"
$azfw.Sku.Tier = "Premium"
Set-AzFirewall -AzureFirewall $azfwAfter the command completes, verify in the portal that the SKU field now shows "Premium." Expect a few minutes of service interruption during the SKU transition.
Here's where most Azure Firewall configuration errors live. The firewall processes rules in a fixed order: DNAT rules first, then network rules, then application rules. A common mistake is writing an application rule to allow traffic to a specific FQDN while a network rule with higher priority is denying all outbound traffic on port 443. The deny wins, and your application rule never gets evaluated.
To audit your current rules, go to your Azure Firewall resource → Rules (classic) or, if you're using Firewall Policy (recommended), navigate to your associated Firewall Policy → Rule collections. Check that rule collection priorities are set correctly, lower numbers mean higher priority. A rule collection at priority 100 fires before one at priority 200.
To add an application rule allowing outbound HTTPS to a specific service, open your Firewall Policy → Application rules → Add rule collection. Fill in:
Name: Allow-OutboundHTTPS
Priority: 200
Action: Allow
Rules:
Name: Allow-WindowsUpdate
Source type: IP Address
Source: 10.0.0.0/16
Protocol: Https:443
Target FQDNs: *.windowsupdate.microsoft.comFor network-level rules (non-HTTP/S traffic), use the Network rules tab instead, specifying source addresses, destination addresses or service tags, and destination ports explicitly.
One thing that trips people up: FQDN-based rules in the network rule collection only work when the DNS proxy is enabled. If you're using FQDNs in network rules and they're not resolving, jump to Step 3 to fix DNS first, then come back here. After saving the rule, give it two to three minutes to propagate, then re-test connectivity from your workload VM.
FQDN-based filtering, one of the most useful features in Azure Firewall Standard and Premium, only works when DNS traffic flows through the firewall itself. Without DNS proxy enabled, the firewall has no visibility into what domain names your workloads are resolving, so FQDN rules match nothing and your application rules based on domain names silently fail.
To enable DNS proxy, open your Firewall Policy → DNS Settings. Toggle DNS Proxy to Enabled. You can leave the DNS server as Azure Default (168.63.129.16) or specify your own custom DNS forwarders if you're running private DNS infrastructure on-premises or in a hub virtual network.
Enabling DNS proxy on the firewall is only half the job. You also need to make your virtual machines send their DNS queries to the firewall's private IP address. Do this at the virtual network level: go to your VNet → DNS Servers → switch from Default (Azure-provided) to Custom → enter the Azure Firewall's private IP address (for example, 10.0.0.4 if that's how your AzureFirewallSubnet is configured).
After saving the VNet DNS settings, you'll need to restart any existing VMs for them to pick up the new DNS server assignment. New VMs will automatically use it. You can verify DNS is flowing through the firewall by checking the AzureFirewallDnsProxy log category in Log Analytics:
AzureDiagnostics
| where Category == "AzureFirewallDnsProxy"
| where TimeGenerated > ago(30m)
| project TimeGenerated, msg_s
| order by TimeGenerated descIf you see DNS query/response entries appearing, DNS proxy is working. If the table is empty, the VMs are still sending DNS elsewhere, double-check the VNet DNS settings and confirm VMs were restarted.
This is the silent killer of Azure Firewall deployments. You can have perfect rules, correct SKU, working DNS, and the firewall will still do nothing if the routing is wrong. Azure Firewall doesn't sit inline by default, you have to explicitly route traffic through it using User Defined Routes (UDRs).
For outbound internet traffic from workload subnets, you need a UDR on each workload subnet with a default route (0.0.0.0/0) pointing to the Azure Firewall's private IP address as the next hop type Virtual appliance. Go to Route tables → Create, then add a route:
Route name: DefaultToFirewall
Address prefix: 0.0.0.0/0
Next hop type: Virtual appliance
Next hop address: [Azure Firewall Private IP, e.g., 10.0.1.4]Then associate this route table with every workload subnet that should have its traffic inspected. Do NOT associate this route table with the AzureFirewallSubnet itself, that creates a routing loop.
For east-west traffic between subnets, you need additional specific routes pointing inter-subnet traffic at the firewall. And if you're using Azure Firewall in a hub-spoke topology with Virtual WAN, Firewall Manager handles most of this routing automatically through Secure Virtual Hub, check that the hub's routing intent is set to send both internet and private traffic through the firewall.
To verify routing is working, use the Effective routes feature: go to a workload VM's NIC → Effective routes. You should see the 0.0.0.0/0 route pointing to your firewall's private IP with next hop type VirtualAppliance. If you see it pointing to Internet instead, the UDR hasn't been applied to that subnet correctly.
Most Azure Firewall issues go undetected for hours because nobody set up monitoring. I get it, when you're rushing to get a deployment done, alerting feels like step 37. But without it, you're finding out about problems from end users, not from your own observability stack.
Azure Firewall exposes both logs and metrics. Logs go to Log Analytics via diagnostic settings (covered in the Quick Fix section above). Metrics go to Azure Monitor automatically. The most useful metrics to alert on are Firewall health state, Data processed, SNAT port utilization, and Throughput.
To set up a health alert, go to your Azure Firewall resource → Alerts → Create alert rule. Select the Firewall health state metric, set the condition to "Less than 100%", and hook it up to an action group that emails your on-call team. A degraded health state (below 100%) means one of the backend instances is having problems and your traffic is routing through reduced capacity.
For SNAT port exhaustion, a problem that surfaces as intermittent connection failures at scale, set an alert on SNAT port utilization at 80% as a warning threshold and 95% as critical. When you exhaust SNAT ports, new outbound connections fail silently from the workload's perspective, which is maddening to debug without this metric. The fix is typically adding more public IP addresses to your firewall (Standard and Premium support up to 250 public IPs):
$pip = New-AzPublicIpAddress -Name "fw-pip-2" -ResourceGroupName "MyRG" `
-Location "eastus" -AllocationMethod Static -Sku Standard
$azfw = Get-AzFirewall -Name "MyFirewall" -ResourceGroupName "MyRG"
$azfw.AddPublicIpAddress($pip)
Set-AzFirewall -AzureFirewall $azfwAfter adding IPs, confirm in the portal under Public IP configuration that the new IP appears in the list. SNAT utilization should drop immediately as Azure starts distributing outbound connections across the additional IP addresses.
Advanced Troubleshooting
When the standard fixes don't resolve your Azure Firewall problem, it's time to go deeper. These are the scenarios I see in enterprise and domain-joined environments where the default troubleshooting paths hit dead ends.
Forced Tunneling Misconfiguration
If your organization requires all internet-bound traffic to route through an on-premises security device before hitting the internet, you need Azure Firewall's forced tunneling mode, available in Standard and Premium SKUs. In forced tunnel mode, the management traffic for Azure Firewall itself uses a separate management NIC and a dedicated subnet called AzureFirewallManagementSubnet (this exact name is required). If you created a forced tunnel setup but skipped creating this subnet or named it differently, the firewall's management plane loses connectivity and the firewall goes into a degraded state. Azure also supports deployment without a public IP address in forced tunnel mode, which is useful for air-gapped environments.
Azure Firewall Manager Policy Inheritance Issues
When you're managing multiple firewalls across subscriptions through Azure Firewall Manager, policy inheritance can produce unexpected behavior. Firewall Manager lets you apply a base policy at the parent level, and child policies can add rules but cannot override parent policy deny rules. If you're seeing traffic blocked that you know you added a rule to allow, check whether there's a parent policy rule collection with a deny that fires first. Navigate to Firewall Manager → Azure Firewall Policies → open the child policy → check the Parent policy field and inspect that policy's rule collections.
TLS Inspection Breaking Applications (Premium SKU)
If you enabled outbound TLS termination on Azure Firewall Premium (TLS forward proxy), applications that pin certificates or use custom certificate authorities will break. The firewall presents its own intermediate certificate for inspected HTTPS flows. Your workloads need to trust the CA cert you configured during Premium setup. Distribute the CA certificate to all VMs via Group Policy or Azure Policy: push it to the Trusted Root Certification Authorities store on each machine. If certain applications must bypass TLS inspection, create an application rule with a lower priority number that allows their FQDNs without inspection.
Event Viewer and Log Analytics Correlation
For connectivity issues on Windows VMs behind Azure Firewall, correlate VM-side events with firewall logs. Check Event Viewer → Windows Logs → System for Event ID 10016 (DCOM permission errors that can block Windows services from reaching Azure endpoints) and Event ID 7023 (service failures that sometimes indicate blocked update traffic). Cross-reference the timestamp of those events with your Log Analytics firewall deny query to confirm the firewall is the blocking point versus something on the VM itself.
IDPS False Positives (Premium SKU)
Azure Firewall Premium's IDPS with 67,000+ signatures across 50+ categories is powerful, but it can produce false positives for legitimate business traffic. If you suspect IDPS is blocking something it shouldn't, check the AzureFirewallIDPS log category in Log Analytics for signature hit details. Each entry includes a signature ID and category. You can create IDPS bypass rules for specific signatures or source/destination pairs in your Firewall Policy → IDPS → Signature rules → add an override for the specific signature ID with action set to Allow.
Prevention & Best Practices
The best Azure Firewall support call is the one you never have to make. Most of the outages and misconfigurations I've described in this guide are preventable with a little upfront planning and some operational habits that become second nature over time.
Start with the right SKU decision at design time. Pulling together your throughput requirements, whether you need active threat intelligence blocking versus alert-only, and whether PCI DSS or IDPS signatures are relevant, before you deploy saves you from a disruptive SKU migration later. Basic is a real option for SMBs with sub-250 Mbps needs, but be honest about your threat model, alert-only threat intelligence isn't the same as active blocking.
Use Azure Firewall Policy instead of classic rules from day one. Classic rules are being deprecated in favor of Firewall Policy, which integrates with Azure Firewall Manager for multi-subscription management. Policies give you version control via ARM templates or Terraform, the ability to back up and restore configurations (you can automate Firewall and Policy backups using Logic Apps as described in official documentation), and policy inheritance for consistent baseline rules across environments.
Implement Infrastructure as Code for your firewall rules. Firewall rules managed manually in the portal drift over time, people add temporary rules that become permanent, and nobody remembers why something was allowed six months ago. Managing rules via Terraform, Bicep, or ARM templates means every change is tracked in source control with a commit message explaining the business reason.
Set up the Azure Firewall workbook in Azure Monitor. Microsoft provides a pre-built workbook template that visualizes firewall traffic, top blocked destinations, threat intelligence hits, and SNAT utilization in a single dashboard. In the Azure portal, go to Azure Monitor → Workbooks → Gallery → search for "Azure Firewall." Deploy it once and use it as your daily operational view.
- Enable diagnostic logging to Log Analytics on day one, retroactive log collection is impossible, so you need this running before the first incident
- Add at least two public IP addresses at deployment time to avoid SNAT port exhaustion as your environment grows
- Use Azure Firewall service tags (like
WindowsUpdateandAzureActiveDirectory) in network rules instead of hardcoding Microsoft IP ranges, service tags update automatically as Microsoft adds infrastructure - Test your routing configuration with Azure Network Watcher's Next Hop tool before declaring the deployment production-ready, confirm workload VM traffic routes through the firewall, not around it
Frequently Asked Questions
What is Azure Firewall and do I actually need it, or can I just use Network Security Groups?
Azure Firewall is a fully stateful, cloud-native network firewall security service, meaning it tracks the complete state of network connections, not just individual packets. Network Security Groups (NSGs) are stateless packet filters that work at the subnet or NIC level: they're great for basic allow/deny rules based on IP and port. Azure Firewall goes much further: it inspects east-west traffic between your Azure workloads AND north-south traffic between Azure and the internet, it understands FQDNs and web categories, it has built-in threat intelligence to alert on or block traffic from known malicious IP addresses and domains, and it provides full SIEM-ready logging. You'll want Azure Firewall any time you need application-layer visibility, outbound internet control, or centralized policy management across multiple virtual networks, NSGs alone can't give you that.
What's the difference between Azure Firewall Basic, Standard, and Premium, which one should I choose?
Azure Firewall Basic is built for small and medium-sized businesses who need essential firewall protection at a lower price point. It tops out at 250 Mbps throughput, runs on two fixed backend VM instances, and only supports threat intelligence in alert mode, it won't block known malicious traffic, just notify you. Azure Firewall Standard adds active threat intelligence blocking, full L3–L7 filtering, web content categories, DNS proxy with custom DNS support, and auto-scales up to 30 Gbps, this is the right choice for most enterprise workloads. Azure Firewall Premium adds signature-based IDPS with over 67,000 signatures across 50+ categories, outbound TLS inspection (TLS forward proxy), URL filtering with full path inspection, and scales up to 100 Gbps, go here for regulated industries or environments that need deep packet inspection. A common practical decision point: if you need to see and control what's inside encrypted HTTPS traffic, you need Premium.
My Azure Firewall rules look correct but traffic is still being blocked, how do I find out which rule is blocking it?
Go to your Log Analytics workspace and query the AzureDiagnostics table filtering on Category == "AzureFirewallNetworkRule" or AzureFirewallApplicationRule" with msg_s contains "Deny". Each log entry tells you the exact source IP, destination IP, port, and protocol that was blocked, plus which rule collection matched. If you see nothing in the logs at all, diagnostic settings aren't configured, go to your Azure Firewall resource → Diagnostic settings and add a setting that sends all log categories to a Log Analytics workspace. One frequently missed case: if your rules use FQDNs in the network rule collection, DNS proxy must be enabled AND your VMs must be using the firewall as their DNS server, otherwise FQDN rules never match.
Azure Firewall SNAT port utilization keeps hitting 100% and connections are failing, how do I fix this?
SNAT port exhaustion happens when your outbound connection volume exceeds the available ports on your public IP addresses. Each public IP on Azure Firewall provides approximately 2,496 SNAT ports per backend instance. The fix is to add more public IP addresses to the firewall, Standard and Premium SKUs support up to 250 public IPs, giving you effectively unlimited SNAT capacity at scale. In the Azure portal, go to your Azure Firewall → Public IP configuration → Add, or use the PowerShell example in Step 5 of this guide. As a proactive measure, set an Azure Monitor alert on the SNAT port utilization metric at 80% threshold so you see this coming before connections actually fail.
How does Azure Firewall Manager work and do I need it if I only have one firewall?
Azure Firewall Manager provides a single place to manage Azure Firewall instances across multiple subscriptions and virtual networks using shared Firewall Policies. It supports firewalls deployed in both traditional virtual networks and in Virtual WAN environments (called Secure Virtual Hubs). If you only have one firewall in one subscription, Firewall Manager is optional but still useful, it gives you policy versioning, parent/child policy inheritance for shared baseline rules, and a unified view of your security posture. Where it becomes genuinely important is when you're running a hub-spoke architecture with multiple spoke subscriptions: Firewall Manager lets you push a consistent set of base rules from a central policy and let teams add their own rules in child policies without overriding the organization's security baseline.
Does Azure Firewall protect against DDoS attacks and web application attacks, or do I need other services too?
Azure Firewall is specifically categorized under Azure's Network Security services, alongside two complementary services that do different jobs. Azure DDoS Protection handles volumetric distributed denial-of-service attacks at the network edge, protecting your public IP addresses from flood-based attacks that Azure Firewall isn't designed to absorb on its own. Azure Web Application Firewall (WAF) protects HTTP/HTTPS applications from OWASP top-10 vulnerabilities, bot attacks, and application-layer exploits, typically deployed on Azure Application Gateway or Azure Front Door in front of your web apps. Azure Firewall's Premium IDPS with 67,000+ signatures does cover a broad range of exploit patterns including malware, phishing, and coin mining at the network level, but for complete coverage of a public-facing web workload, the recommended architecture is Azure Firewall for network-level east-west and north-south control, WAF on Application Gateway for web app protection, and DDoS Protection for volumetric attack mitigation.