Microsoft Azure — Azure Firewall & Firewall Manager

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure firewall & firewall manager with production-ready configurations, best practices, and hands-on examples.

Azure Firewall vs. Network Security Groups: When to Use Which

Azure Firewall is a managed, cloud-native network security service that protects your Azure Virtual Network resources. It's a stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Network Security Groups (NSGs) filter traffic at the subnet or NIC level using 5-tuple rules (source, destination, port, protocol, direction). The key difference: NSGs are distributed, stateless (for inbound) or stateful (for outbound) access control lists, while Azure Firewall is a centralized, fully stateful inspection engine with application (FQDN) and network (L3-L4) filtering, threat intelligence, and DNS proxy. Use NSGs for simple east-west traffic segmentation within a VNet (e.g., blocking port 3389 between subnets). Use Azure Firewall for north-south traffic (internet ingress/egress), hybrid connections, and when you need centralized logging, threat intelligence feeds, or FQDN-based rules. In production, never rely solely on NSGs for internet-facing workloads; always place an Azure Firewall in the hub for inspection. A common failure mode is assuming NSGs provide the same logging depth—they don't. Azure Firewall logs full session details, while NSG flow logs require additional setup and lack application-level visibility.

resource "azurerm_firewall" "fw" {
  name                = "fw-hub-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  sku_name            = "AZFW_VNet"
  sku_tier            = "Standard"
  ip_configuration {
    name                 = "fw-ipconfig"
    subnet_id            = azurerm_subnet.fw_subnet.id
    public_ip_address_id = azurerm_public_ip.fw_pip.id
  }
}

resource "azurerm_network_security_group" "nsg" {
  name                = "nsg-app-subnet"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  security_rule {
    name                       = "AllowHTTP"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefixes    = ["VirtualNetwork"]
    destination_address_prefix = "*"
  }
}

Azure Firewall Manager: Centralized Policy Management at Scale

Azure Firewall Manager provides a single pane of glass to manage multiple Azure Firewalls across different regions and subscriptions. It introduces the concept of firewall policies—a reusable, versioned set of rule collections (network, application, NAT, and threat intelligence) that can be applied to one or more firewalls. This is a game-changer for enterprises with hub-and-spoke topologies or multiple VNets. Instead of configuring each firewall individually, you create a policy in Firewall Manager and associate it with firewalls. Policies support inheritance: a parent policy can be applied to a root management group, and child policies can override specific rule collections. This aligns with Azure's governance model. Firewall Manager also integrates with Azure Virtual WAN for secured virtual hubs, enabling automatic routing and inspection. In production, use Firewall Manager to enforce baseline rules (e.g., block all inbound RDP) across all environments, then allow per-application teams to manage their own rule collections via delegated policies. A common pitfall is not using policy analytics—Firewall Manager provides insights into rule hits and idle rules, which are critical for cleanup. Without it, rule bloat leads to performance degradation and security gaps.

az network firewall policy create \
  --name fw-policy-prod \
  --resource-group rg-hub-prod \
  --location eastus \
  --threat-intel-mode Alert \
  --sku Standard \
  --base-policy /subscriptions/.../firewallPolicies/fw-policy-base

az network firewall policy rule-collection-group create \
  --name DefaultNetworkRuleCollectionGroup \
  --policy-name fw-policy-prod \
  --resource-group rg-hub-prod \
  --priority 200 \
  --rule-collections '[{"name":"AllowOutboundHTTP","priority":100,"action":"Allow","rules":[{"name":"AllowWeb","protocols":[{"port":80,"protocolType":"TCP"},{"port":443,"protocolType":"TCP"}],"sourceAddresses":["10.0.0.0/8"],"destinationAddresses":["*"],"destinationPorts":["80","443"]}]}]'

Designing a Hub-and-Spoke Network with Azure Firewall

The hub-and-spoke model is the de facto standard for enterprise networking in Azure. The hub VNet contains shared services like Azure Firewall, VPN/ExpressRoute gateways, and DNS. Spoke VNets connect to the hub via VNet peering and route all traffic to the firewall for inspection. To force traffic through the firewall, you must configure User-Defined Routes (UDRs) on each spoke subnet with the next hop as the firewall's private IP. For internet-bound traffic, the firewall's public IP is used for SNAT. For on-premises traffic, the firewall inspects and forwards to the gateway. Key design considerations: (1) The firewall subnet must be named 'AzureFirewallSubnet' with a /26 or larger. (2) Use Azure Firewall Manager policies to enforce consistent rules across spokes. (3) For high availability, deploy at least two firewalls in an active-active configuration (Standard or Premium SKU). (4) Monitor firewall metrics like SNAT port utilization—exhaustion causes connection failures. In production, we learned the hard way that spoke VNets must not have a default route (0.0.0.0/0) pointing to the internet; always route through the firewall. Also, ensure the firewall's outbound SNAT ports are sized correctly: each firewall instance provides 2,496 ports per public IP. Use multiple public IPs if needed.

resource "azurerm_virtual_network" "hub" {
  name          = "vnet-hub-prod"
  address_space = ["10.0.0.0/16"]
  location      = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

resource "azurerm_subnet" "fw_subnet" {
  name                 = "AzureFirewallSubnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.hub.name
  address_prefixes     = ["10.0.1.0/26"]
}

resource "azurerm_virtual_network" "spoke" {
  name          = "vnet-spoke-prod"
  address_space = ["10.1.0.0/16"]
  location      = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

resource "azurerm_virtual_network_peering" "hub-to-spoke" {
  name                      = "hub-to-spoke"
  resource_group_name       = azurerm_resource_group.rg.name
  virtual_network_name      = azurerm_virtual_network.hub.name
  remote_virtual_network_id = azurerm_virtual_network.spoke.id
  allow_forwarded_traffic   = true
  allow_gateway_transit     = false
  use_remote_gateways       = false
}

resource "azurerm_route_table" "spoke_rt" {
  name                = "rt-spoke-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  route {
    name           = "to-firewall"
    address_prefix = "0.0.0.0/0"
    next_hop_type  = "VirtualAppliance"
    next_hop_in_ip_address = azurerm_firewall.fw.ip_configuration[0].private_ip_address
  }
}

Application Rules: FQDN Filtering and TLS Inspection

Azure Firewall's application rules allow or deny outbound traffic based on fully qualified domain names (FQDNs), not just IP addresses. This is critical for controlling which external services your workloads can access. For example, you can allow only .microsoft.com and block everything else. Application rules support HTTP/HTTPS and TLS inspection (Premium SKU). TLS inspection decrypts outbound traffic, inspects the payload, and re-encrypts it. This enables detection of malware in encrypted traffic. However, TLS inspection introduces latency and requires certificate management—you must install the firewall's CA certificate on clients. In production, use TLS inspection selectively: for traffic to untrusted destinations, not for internal services or well-known trusted endpoints (e.g., Office 365). A common mistake is creating overly permissive application rules with wildcards (e.g., .com). This defeats the purpose. Instead, use FQDN tags for Azure services (e.g., AzureCloud, WindowsUpdate) and specific FQDNs for third parties. Monitor application rule hit counts to identify unused rules. Also, be aware that application rules are evaluated after network rules; if a network rule allows traffic to an IP, the application rule is not checked. So, to enforce FQDN filtering, ensure no network rule allows the same traffic.

az network firewall policy rule-collection-group collection add-filter-collection \
  --policy-name fw-policy-prod \
  --resource-group rg-hub-prod \
  --rcg-name DefaultApplicationRuleCollectionGroup \
  --name AllowMicrosoft \
  --collection-priority 200 \
  --action Allow \
  --rule-name AllowMsft \
  --rule-type ApplicationRule \
  --source-addresses 10.0.0.0/8 \
  --protocols http=80 https=443 \
  --fqdn-tags AzureCloud \
  --fqdn-list "*.microsoft.com" "*.azure.com"

Network Rules: Fine-Grained IP and Port Control

Network rules in Azure Firewall allow or deny traffic based on source/destination IP addresses, ports, and protocols (TCP, UDP, ICMP). They are stateless in definition but stateful in execution—the firewall automatically allows return traffic. Network rules are ideal for controlling traffic to on-premises networks via VPN/ExpressRoute, or to specific Azure services that don't support FQDN tags. For example, you can allow traffic from a spoke to a specific on-premises IP range on port 443. Network rules are evaluated before application rules. If a network rule matches, the traffic is allowed without application rule inspection. This is important: if you want to enforce FQDN filtering, do not create a network rule that allows the same traffic. In production, use network rules sparingly and prefer application rules for outbound internet traffic. Network rules are also used for DNAT (destination NAT) to expose internal services via the firewall's public IP. For DNAT, you create a NAT rule collection that translates the destination IP and port. A common failure mode is forgetting to add a corresponding network rule to allow the translated traffic. Also, be mindful of SNAT port exhaustion: each firewall public IP provides 2,496 ports. Monitor SNAT port usage in Azure Monitor and add more public IPs if utilization exceeds 80%.

az network firewall policy rule-collection-group collection add-filter-collection \
  --policy-name fw-policy-prod \
  --resource-group rg-hub-prod \
  --rcg-name DefaultNetworkRuleCollectionGroup \
  --name AllowOnPrem \
  --collection-priority 100 \
  --action Allow \
  --rule-name AllowSQL \
  --rule-type NetworkRule \
  --source-addresses 10.0.0.0/8 \
  --destination-addresses 192.168.1.0/24 \
  --destination-ports 1433 \
  --protocols TCP

Threat Intelligence and IDPS: Proactive Threat Detection

Azure Firewall includes threat intelligence based on Microsoft's Threat Intelligence feeds, which block traffic to/from known malicious IPs and domains. This is enabled at the policy level with three modes: Off, Alert only, and Alert and Deny. In production, always use Alert and Deny for internet-facing traffic. Additionally, the Premium SKU includes Intrusion Detection and Prevention System (IDPS) with signature-based inspection. IDPS can detect and block exploits, malware, and other attacks in real-time. It supports both inbound and outbound inspection. You can configure IDPS to alert or block traffic matching signatures. A key feature is the ability to bypass IDPS for trusted traffic (e.g., from specific IPs) to reduce false positives. In production, start with IDPS in alert mode to understand your traffic patterns, then switch to block mode after tuning. Monitor IDPS logs for signature hits—they often reveal compromised workloads. A common failure mode is not updating threat intelligence feeds; they are updated automatically by Microsoft, but you must ensure your firewall policy has threat intelligence enabled. Also, be aware that IDPS can impact performance; test in a non-production environment first.

az network firewall policy update \
  --name fw-policy-prod \
  --resource-group rg-hub-prod \
  --threat-intel-mode "Alert and Deny"

az network firewall policy intrusion-detection add-configuration \
  --policy-name fw-policy-prod \
  --resource-group rg-hub-prod \
  --mode "Alert" \
  --signature-overrides '[{"id":"2000001","mode":"Off"}]'

Logging and Monitoring: Azure Firewall Diagnostics

Azure Firewall integrates with Azure Monitor for logging and metrics. You must enable diagnostic settings to send logs to Log Analytics, Storage Account, or Event Hub. Key log categories: AzureFirewallApplicationRule (application rule hits), AzureFirewallNetworkRule (network rule hits), AzureFirewallDnsProxy (DNS queries), and AzureFirewallThreatIntel (threat intelligence matches). Metrics include SNAT port utilization, throughput, and firewall health. In production, send logs to a centralized Log Analytics workspace for cross-resource analysis. Use KQL queries to detect anomalies: e.g., sudden spikes in denied traffic, or high SNAT port usage. Set up alerts for SNAT port exhaustion (>80%), firewall health degradation, and threat intel hits. A common mistake is not enabling DNS proxy logs—these are essential for troubleshooting FQDN resolution failures. Also, be aware that log ingestion costs money; estimate your log volume and set a daily cap. For long-term retention, export logs to a storage account with a lifecycle policy. In a recent incident, we traced a breach to a firewall rule that was too permissive; the logs showed the attacker's IP hitting an application rule that allowed *.com. We immediately tightened the rule and blocked the IP.

az monitor diagnostic-settings create \
  --name fw-diagnostics \
  --resource /subscriptions/.../firewalls/fw-hub-prod \
  --workspace /subscriptions/.../workspaces/law-prod \
  --logs '[
    {"category": "AzureFirewallApplicationRule", "enabled": true, "retentionPolicy": {"days": 30, "enabled": true}},
    {"category": "AzureFirewallNetworkRule", "enabled": true, "retentionPolicy": {"days": 30, "enabled": true}},
    {"category": "AzureFirewallDnsProxy", "enabled": true, "retentionPolicy": {"days": 30, "enabled": true}},
    {"category": "AzureFirewallThreatIntel", "enabled": true, "retentionPolicy": {"days": 90, "enabled": true}}
  ]' \
  --metrics '[
    {"category": "AllMetrics", "enabled": true, "retentionPolicy": {"days": 30, "enabled": true}}
  ]'

Automating Azure Firewall Deployments with Infrastructure as Code

Azure Firewall and Firewall Manager can be fully automated using Terraform, ARM templates, Bicep, or Azure CLI. Infrastructure as Code (IaC) ensures consistent deployments across environments and enables version control. Key resources to define: firewall, firewall policy, rule collection groups, and diagnostic settings. Use modules to encapsulate common patterns (e.g., hub-and-spoke with firewall). In Terraform, use the azurerm_firewall_policy resource with rule_collection_group blocks. For Firewall Manager, use azurerm_firewall_policy_rule_collection_group. Always store state files securely (e.g., Azure Storage with encryption). In production, integrate IaC with CI/CD pipelines (Azure DevOps, GitHub Actions) to deploy changes after peer review. A common pitfall is not handling rule collection group priorities correctly—they must be unique within a policy. Also, be careful with Terraform's state: if you manually add a rule via the portal, Terraform will detect drift and may overwrite it. Use lifecycle policies to prevent accidental deletion. Another tip: use policy inheritance to reduce duplication; define base rules in a parent policy and only override in child policies. This makes changes easier and reduces the risk of misconfiguration.

resource "azurerm_firewall_policy" "policy" {
  name                = "fw-policy-prod"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  threat_intelligence_mode = "Alert and Deny"
  sku                 = "Standard"
}

resource "azurerm_firewall_policy_rule_collection_group" "network" {
  name               = "DefaultNetworkRuleCollectionGroup"
  firewall_policy_id = azurerm_firewall_policy.policy.id
  priority           = 200
  network_rule_collection {
    name     = "AllowOutboundHTTP"
    priority = 100
    action   = "Allow"
    rule {
      name                  = "AllowWeb"
      protocols             = ["TCP"]
      source_addresses      = ["10.0.0.0/8"]
      destination_addresses = ["*"]
      destination_ports     = ["80", "443"]
    }
  }
}

resource "azurerm_firewall" "fw" {
  name                = "fw-hub-prod"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  sku_name            = "AZFW_VNet"
  sku_tier            = "Standard"
  firewall_policy_id  = azurerm_firewall_policy.policy.id
  ip_configuration {
    name                 = "fw-ipconfig"
    subnet_id            = azurerm_subnet.fw_subnet.id
    public_ip_address_id = azurerm_public_ip.fw_pip.id
  }
}

Forced Tunneling: Routing Internet Traffic Through On-Premises

Forced tunneling routes all internet-bound traffic from Azure Firewall to a specified next hop — typically an on-premises firewall or NVA — instead of letting it egress directly to the internet. This is critical for organizations that require all internet traffic to pass through a central security inspection point, often for compliance (PCI-DSS, SOC) or data sovereignty reasons. To configure forced tunneling, deploy Azure Firewall without a public IP address on the data path (management NIC uses a separate subnet for Azure management traffic). Create a route table on the AzureFirewallSubnet with a default route (0.0.0.0/0) pointing to the next hop (e.g., an on-premises firewall via VPN/ExpressRoute). Enable 'Allow Forwarded Traffic' on VNet peering for spoke-to-hub traffic. Azure Firewall Standard and Premium support forced tunneling; Basic does not. In production, forced tunneling also requires careful planning: ensure the on-premises firewall can handle the additional traffic volume, and monitor the VPN/ExpressRoute circuit for bandwidth saturation. Use Azure Monitor to track firewall throughput and set up alerts. If the forced tunnel fails, Azure Firewall drops internet-bound traffic — there is no fallback to direct egress. For high availability, deploy active-active firewalls with forced tunneling.

#!/bin/bash
# Create firewall subnet (must be /26 or larger)
az network vnet subnet create \
  --name AzureFirewallSubnet \
  --resource-group rg-hub-prod \
  --vnet-name hub-vnet \
  --address-prefix 10.0.1.0/26

# Create route table with default route to on-premises
az network route-table create \
  --name fw-rt \
  --resource-group rg-hub-prod \
  --location eastus

az network route-table route create \
  --route-table-name fw-rt \
  --resource-group rg-hub-prod \
  --name DefaultToOnPrem \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 192.168.1.1

# Associate route table with firewall subnet
az network vnet subnet update \
  --name AzureFirewallSubnet \
  --resource-group rg-hub-prod \
  --vnet-name hub-vnet \
  --route-table fw-rt

# Deploy firewall in forced tunnel mode (no public IP on data path)
az network firewall create \
  --name prod-fw \
  --resource-group rg-hub-prod \
  --location eastus \
  --sku AZFW_VNet \
  --tier Standard \
  --firewall-policy /subscriptions/.../firewallPolicies/fw-policy-prod \
  --virtual-hub-route-table-v1 '{"routes":[{"addressPrefix":"0.0.0.0/0","nextHopIpAddress":"192.168.1.1"}]}'

DNS Proxy and Custom DNS: FQDN Resolution in Firewall Policies

Azure Firewall's DNS proxy enables reliable FQDN filtering by proxying DNS queries from virtual networks to your desired DNS server. When DNS proxy is enabled, the firewall listens on port 53 and forwards DNS queries to the configured DNS servers. This ensures that FQDN filtering in application rules works correctly — without it, the firewall relies on the VM's DNS resolution, which can lead to inconsistent filtering. Custom DNS allows you to configure Azure Firewall to use your own DNS server(s) while ensuring the firewall's own outbound dependencies are resolved via Azure DNS (168.63.129.16). You can configure a single DNS server or multiple for redundancy. In production, always enable DNS proxy on Azure Firewall when using application rules with FQDNs. Without DNS proxy, the firewall uses the source VM's DNS cache, which may contain stale or incorrect IPs. DNS proxy logs are essential for troubleshooting FQDN resolution failures — enable the AzureFirewallDnsProxy log category in diagnostic settings. Also configure custom DNS servers for hybrid scenarios where on-premises hostnames need resolution. The combination of DNS proxy and custom DNS ensures that all outbound traffic is filtered against the most current FQDN-to-IP mappings.

#!/bin/bash
# Enable DNS proxy on firewall policy
az network firewall policy update \
  --name fw-policy-prod \
  --resource-group rg-hub-prod \
  --dns-settings '{"enableProxy": true, "servers": ["10.0.4.4", "10.0.4.5"]}'

# Verify DNS proxy is enabled
az network firewall policy show \
  --name fw-policy-prod \
  --resource-group rg-hub-prod \
  --query 'dnsSettings'

# Enable DNS proxy logs in diagnostic settings
az monitor diagnostic-settings create \
  --name fw-dns-diag \
  --resource /subscriptions/.../firewalls/prod-fw \
  --workspace /subscriptions/.../workspaces/law-prod \
  --logs '[{"category": "AzureFirewallDnsProxy", "enabled": true}]'

Policy Analytics: Optimizing Firewall Rules Over Time

Azure Firewall Policy Analytics provides insights into rule utilization over time, helping you identify unused or over-permissive rules, optimize rule performance, and maintain clean security policies. Policy Analytics analyzes firewall logs to show which rules are being hit, how often, and by what traffic patterns. It surfaces idle rules (no hits in 30+ days), rules with broad source/destination ranges that could be narrowed, and rules approaching their hit count limits. In production, run Policy Analytics monthly to clean up stale rules. Common findings: rules created for temporary access that were never removed, rules with 'Any' source that should be scoped to specific IP ranges, and duplicate rules that cancel each other out. Policy Analytics also recommends optimal rule ordering to improve performance. Access it via Azure Firewall Manager under 'Policy Analytics'. Export reports for compliance audits and integrate with Azure Monitor for scheduled analysis. A clean rule set improves firewall throughput by reducing the rule evaluation tree depth. For organizations with multiple firewalls, use Policy Analytics across all policies to enforce consistent rule hygiene standards.

#!/bin/bash
# Get policy analytics report (via Firewall Manager)
az network firewall policy analytics list \
  --policy-name fw-policy-prod \
  --resource-group rg-hub-prod \
  --query "[?hitCount==\`0\`].{ruleName: name, ruleCollection: ruleCollectionName}"

# Export policy analytics to Log Analytics
az monitor diagnostic-settings create \
  --name policy-analytics \
  --resource /subscriptions/.../firewallPolicies/fw-policy-prod \
  --workspace /subscriptions/.../workspaces/law-prod \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'