Azure Firewall enforces three distinct rule collections processed in a strict priority order. Understanding all three is essential to designing a secure hub and spoke topology.

The three rule types are processed top to bottom — DNAT first, then network, then application. A match at any layer stops processing. If nothing matches, traffic is implicitly denied.

Rule Type 1 — DNAT Rules

Destination Network Address Translation rewrites the destination IP (and optionally port) of inbound traffic hitting the firewall’s public IP, redirecting it to a private backend inside a spoke VNet.

What it does

Internet client → Firewall public IP (52.x.x.x:443)
                        ↓  DNAT rule fires
                  Rewrites destination to 10.1.4.5:443
                        ↓
                  Backend VM in production spoke

Example DNAT rules

Key rules about DNAT

• DNAT rules implicitly create a matching network rule to allow the translated traffic through — you don’t need a separate network rule for the return path.
• DNAT only applies to inbound traffic — traffic arriving at the firewall’s public IP from outside.
• You cannot DNAT to a broadcast or multicast address.
• After translation, the packet is treated as if it came from the firewall’s private IP — so your backend VMs see the firewall, not the original client. Preserve source IP with SNAT if needed.

Rule Type 2 — Network Rules

Network rules are Layer 3/4 filters — they match on source IP, destination IP, port, and protocol. No payload inspection. This is the right tool for non-HTTP traffic: SQL, RDP, SMB, DNS, NTP, custom protocols.

What it does

Spoke VM (10.1.2.5) → SQL Server (10.3.4.10:1433)
        ↓
Network rule: allow src=10.1.0.0/16 dest=10.3.4.10 port=1433 proto=TCP
        ↓
Traffic passes — no application-layer inspection

Example network rules

Network rule features

IP Groups — reusable objects containing lists of IPs and CIDRs, so you don’t repeat 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 in every rule:

IPGroup: "all-spokes" = [10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, 10.4.0.0/16]

FQDN in network rules — you can use FQDNs as destinations in network rules (e.g. *.windows.update.com) but only for TCP/UDP. The firewall resolves the FQDN using its DNS settings and matches on the resolved IP.

Service Tags — Microsoft-managed groups of IP ranges for Azure services:

Source: 10.0.0.0/8  →  Destination: AzureMonitor  →  Port: 443  →  Allow

Common tags: AzureCloud, AzureMonitor, Storage, Sql, WindowsUpdate, MicrosoftDefenderForEndpoint

Rule Type 3 — Application Rules

Application rules operate at Layer 7 — they can inspect the HTTP/HTTPS host header and URL path, enforce FQDN allow-lists, apply web category filtering, and (with Premium SKU) perform full TLS inspection.

What it does

Spoke VM → HTTPS request to api.github.com
        ↓
Application rule: allow src=10.1.0.0/16 target=*.github.com proto=Https
        ↓
Firewall checks SNI / Host header — matches rule
        ↓
Traffic passes (or inspected if TLS inspection enabled)

Example application rules

FQDN Tags — Microsoft-managed bundles

Instead of listing dozens of Microsoft service URLs manually, use built-in FQDN tags:

Azure Firewall SKUs

TLS inspection (Premium only) decrypts HTTPS traffic, inspects the payload with IDPS signatures, then re-encrypts it. Requires deploying a CA certificate chain trusted by all spoke VMs — typically distributed via Group Policy or Intune.

Firewall Policy vs Classic Rules

Modern Azure Firewall uses Firewall Policy — an ARM resource that holds all rule collections and can be shared across multiple firewall instances:

Firewall Policy (parent — global rules)
        ↓  inheritance
Firewall Policy (child — environment-specific rules)
        ↓  applied to
Azure Firewall instance (hub VNet)

This lets you enforce baseline rules (e.g. deny dev→prod) at the parent policy level across all environments, while child policies add environment-specific rules. Child policies cannot override parent deny rules.

Rule Processing Priority — the Full Picture

Priority 100 (lowest number = highest priority)
    DNAT collection A   → rules evaluated top to bottom
    DNAT collection B
Priority 200
    Network collection A  → IP/port rules
    Network collection B
Priority 300
    Application collection A  → FQDN / URL rules
    Application collection B
Priority 65000 (built-in)
    Allow Azure infrastructure FQDNs (IMDS, DNS, etc.)
Priority 65500 (built-in)
    Implicit deny all

Rule collections within each type are evaluated by priority number — lowest number wins. Within a collection, rules are evaluated top to bottom and the first match wins.