Azure Firewall Policy and Rule Collections

Azure Firewall Policy is a resource that defines a set of rules governing traffic flow through one or more Azure Firewall instances. It replaces the older approach of configuring rules directly on each firewall. With policy, you create a single policy and associate it with multiple firewalls, ensuring consistent security rules across your environment. The policy is versioned and can be deployed to multiple regions. It supports three rule collection types: DNAT (Destination Network Address Translation), Network, and Application. Each rule collection has a priority (100–65000) and a collection action (Allow or Deny). Rules within a collection are evaluated in priority order, and the first matching rule determines the action.

When a packet arrives at an Azure Firewall, the firewall performs the following steps in order: 1. DNAT rule processing: Check DNAT rule collections first (lowest priority number first). If a match is found, the destination address/port is translated, and the packet is forwarded to the internal target. No further rule processing occurs for that packet. 2. Network rule processing: If no DNAT match, check Network rule collections (lowest priority first). Network rules filter based on source IP, destination IP, protocol (TCP/UDP/ICMP), and port. The first match determines the action (Allow/Deny). If Deny, the packet is dropped. 3. Application rule processing: If no Network rule match, check Application rule collections (lowest priority first). Application rules filter based on fully qualified domain names (FQDNs), HTTP/HTTPS headers, and TLS Server Name Indication (SNI). The first match determines the action. Application rules only apply to outbound traffic destined for the internet or Azure services. 4. Default deny: If no rule in any collection matches, the packet is denied by default.

Policies are managed via Azure Portal, Azure CLI, PowerShell, or ARM templates. Common CLI commands:

# Create a firewall policy
az network firewall policy create --name MyPolicy --resource-group MyRG --location eastus

# Add a rule collection group
az network firewall policy rule-collection-group create --name MyGroup --priority 200 --policy-name MyPolicy --resource-group MyRG

# Add a network rule collection
az network firewall policy rule-collection-group collection add-filter-collection \
  --resource-group MyRG --policy-name MyPolicy --rcg-name MyGroup \
  --name AllowWeb --priority 100 --action Allow \
  --rule-name AllowHTTP --rule-type Network --source-addresses '*' \
  --destination-addresses '10.0.0.4' --destination-ports 80 --protocols TCP

# Show effective rules for a firewall
az network firewall show --name MyFirewall --resource-group MyRG --query 'ipConfigurations[0].privateIPAddress'

To verify policy application, use Azure Firewall Manager's "Effective Rules" view or run diagnostic logs. The firewall logs all rule matches (allow/deny) to Azure Monitor.

When a packet enters the firewall, the processing order is strict: 1. DNAT rules (lowest priority first) 2. Threat intelligence (if enabled) – if threat found, action taken (alert/deny) and packet is not processed further 3. Network rules (lowest priority first) 4. Application rules (lowest priority first) 5. Default deny

Important: DNAT rules are evaluated before any other rules. This means that even if a Network rule denies traffic to a public IP, a DNAT rule with higher priority (lower number) will still translate and forward the packet. Also, Network rules can override Application rules if a match occurs earlier in the chain.

Each rule collection group has a priority (100–65000). Within a group, rule collections are evaluated by their priority. Groups are evaluated in priority order. This allows you to organize rules into categories (e.g., infrastructure, internet, DMZ) and control the order of evaluation across groups.

Azure Firewall Manager provides Policy Analytics, which shows how many times each rule has been hit, allowing you to identify unused or overpermissive rules. This is critical for hardening.

Each rule collection has an action (Allow/Deny) that applies to all matching rules within it. However, individual rules within a collection can have different actions? No – the collection action is applied to all rules in that collection. To have different actions, use separate rule collections.

When you assign a parent policy to a firewall, the firewall inherits all rule collections from the parent. You can then add local rule collections that are evaluated according to their priority relative to parent collections. The parent policy's rule collections are always evaluated first (they have lower priority numbers by design). Local rule collections with a lower priority number (higher priority) can override parent rules. This is a common exam scenario: a child firewall needs to allow a specific IP that the parent denies – create a local rule collection with priority lower than the parent's deny rule.

By default, all traffic is denied. You must explicitly create allow rules. The firewall logs all denied traffic (if logging is enabled). Use diagnostic logs to troubleshoot.

Enable diagnostic logs for Azure Firewall (AzureFirewallNetworkRule, AzureFirewallApplicationRule, AzureFirewallDnsProxy). Query Log Analytics:

AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where OperationName == "Deny"
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, Protocol, Action

This helps identify blocked traffic and adjust rules.

Understanding this order is crucial for designing effective policies.

A multinational company uses Azure Virtual WAN with a secured hub in each region. They create a single parent firewall policy named 'Global-Policy' that contains baseline Network rules (allow RDP from admin IPs, deny all other inbound) and Application rules (allow *.office.com, deny all other internet). Each regional hub has a child firewall that inherits the parent policy. The regional security team adds local rule collections to allow specific SaaS applications required locally (e.g., a local CRM). They use rule collection priorities to ensure local rules are evaluated before parent rules where needed. This setup ensures consistent security baseline while allowing regional flexibility. Performance is monitored via Azure Firewall metrics (throughput, SNAT port utilization). Common issue: SNAT port exhaustion due to many outbound connections. Mitigation: add multiple public IPs to the firewall or use a NAT gateway for outbound.

An e-commerce company hosts a web application on Azure VMs behind an Azure Firewall. They configure DNAT rules to translate public IP traffic to the web server's private IP on port 443. They also enable TLS inspection to decrypt and inspect HTTPS traffic for SQL injection attempts. A parent policy defines strict Application rules to allow only traffic to the specific web server FQDN and deny all other outbound. They use IDPS to detect and block exploit attempts. Misconfiguration: initially, they placed a Network rule that denied all inbound traffic from the internet, forgetting that DNAT rules are processed first. The DNAT still worked, but they thought the deny was effective. After logs showed traffic flowing, they corrected by removing the Network deny. They also learned to use threat intelligence to block known malicious IPs.

After an acquisition, two companies need to connect their Azure environments. They use Azure Firewall Manager to create a policy that allows cross-connectivity between the two VNets via forced tunneling. The policy includes Network rules to allow traffic between specific IP ranges on necessary ports. They also add Application rules to allow access to common SaaS tools. The challenge is overlapping IP ranges. They use Azure Firewall's DNAT to translate overlapping addresses. This requires careful planning of NAT rules. A common mistake is to use Network rules with the same priority for both allow and deny, causing unpredictable behavior. They learned to use separate rule collections with distinct priorities.