9.1 Azure Firewall Architecture & Rule Processing

Azure Firewall Architecture & Rule Processing

Azure Firewall is a cloud-native, intelligent, stateful firewall-as-a-service (FWaaS) that provides comprehensive Layer 3 through Layer 7 threat protection for Azure Virtual Network workloads. Unlike traditional virtual network appliances (NVAs) deployed on standalone virtual machine scale sets, Azure Firewall features built-in high availability, unrestricted cloud elasticity, automated scaling, and zero maintenance overhead.

Designing and deploying Azure Firewall in enterprise production environments requires an exact understanding of subnet provisioning constraints, SKU feature boundaries, TLS cryptographic inspection pipelines, and the strict sequential logic of the Azure Firewall rule processing engine.

1. Core Architecture & Specialized Subnet Requirements

Azure Firewall operates as a fully managed cluster of underlying compute instances injected into your virtual network. As network throughput increases, the Azure fabric automatically scales the underlying instances out (up to a maximum of 100 compute nodes) to sustain line-rate performance.

+-----------------------------------------------------------------------------+
|                     AZURE FIREWALL SUBNET ARCHITECTURE                      |
|                                                                             |
|   Virtual Network: Hub-VNet (10.100.0.0/16)                                 |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | Subnet: AzureFirewallSubnet (10.100.0.0/26 - Minimum /26 Required)  |   |
|   | - Hosts data-plane inspection instances                             |   |
|   | - Associated with 1 to 250 Standard SKU Public IP addresses         |   |
|   | - STRICT CONSTRAINT: No Network Security Groups (NSGs) permitted    |   |
|   | - Default Route (0.0.0.0/0) -> Internet (or on-prem in forced tun) |   |
|   +---------------------------------------------------------------------+   |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | Subnet: AzureFirewallManagementSubnet (10.100.0.64/26 - Required     |   |
|   |         ONLY for Forced Tunneling architectures)                    |   |
|   | - Carries platform management, health probes, and telemetry         |   |
|   | - STRICT CONSTRAINT: Must have direct Internet egress (0.0.0.0/0)    |   |
|   | - Associated with a dedicated management Standard Public IP         |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Subnet Sizing & Allocation Constraints

1. AzureFirewallSubnet (Mandatory):
   • Sizing: Must be sized at /26 (64 total IP addresses) or larger (e.g., /25, /24). Azure Firewall provisions multiple internal IP addresses as it autoscales; a /26 provides 59 usable host IPs, ensuring sufficient address headroom for dynamic scaling.
   • Naming: The subnet name must match the exact case-sensitive string AzureFirewallSubnet.
   • No Non-Firewall Resources: No virtual machines, application gateways, or other endpoints may reside in this subnet.
   • NSG Prohibition: Network Security Groups cannot be associated with AzureFirewallSubnet. Doing so breaks platform connectivity and causes deployment failure.
2. AzureFirewallManagementSubnet (Conditional):
   • Sizing: Sized at /26 minimum.
   • Required strictly when Forced Tunneling is enabled.
   • Separates customer data-plane egress from Microsoft platform health probing, diagnostic logging, and operational management traffic.

Public IP Allocation & Availability Zones

• Azure Firewall requires at least one Standard SKU Public IP Address for outbound Source Network Address Translation (SNAT) and inbound Destination NAT (DNAT).
• Enterprises can associate up to 250 Public IP addresses to a single Azure Firewall instance, expanding SNAT port capacity to prevent port exhaustion during heavy concurrent outbound traffic spikes (each public IP provides 64,000 ephemeral SNAT ports).
• Availability Zone Resilience: Azure Firewall can be deployed across Availability Zones (1, 2, 3). When configured as zone-redundant, the SLA increases to 99.99% availability, and instances are automatically distributed across distinct physical datacenter zones.

2. Azure Firewall SKU Comparison: Basic, Standard & Premium

Choosing the correct SKU depends on throughput requirements, inspection depth (Layer 4 vs. Layer 7), and advanced security compliance standards.

[!IMPORTANT] Rule Management Evolution: While Azure Firewall historically supported "Classic Rules" configured directly on the firewall resource, modern deployments and the AZ-700 blueprint mandate Azure Firewall Policy as the primary configuration vehicle. Basic and Premium SKUs exclusively require Firewall Policies.

3. Rule Processing Engine Hierarchy & Logic

The Azure Firewall engine processes network packets through a rigid, non-negotiable sequential pipeline. Understanding the exact order of operations is essential for troubleshooting traffic drops and designing granular security controls.

The Three-Tier Sequential Processing Pipeline

+-----------------------------------------------------------------------------+
|                   AZURE FIREWALL RULE PROCESSING ORDER                      |
|                                                                             |
|   [ Packet Ingress ]                                                        |
|          |                                                                  |
|          v                                                                  |
|   +---------------------------------------------------------------------+   |
|   | STEP 1: DNAT Rules (Destination Network Address Translation)        |   |
|   | - Matches inbound public traffic targeting Firewall Public IPs.     |   |
|   | - Translates Public Destination IP:Port -> Private Backend IP:Port. |   |
|   | - CRITICAL: Automatically applies an implicit Network Allow rule!   |   |
|   +---------------------------------------------------------------------+   |
|          | (If no DNAT match or outbound flow)                              |
|          v                                                                  |
|   +---------------------------------------------------------------------+   |
|   | STEP 2: Network Rules (Layer 3 / Layer 4 Filtering)                 |   |
|   | - Evaluates Source IP, Protocol (TCP/UDP/ICMP), Port, Destination.  |   |
|   | - TERMINATING ENGINE: If an ALLOW or DENY match occurs, processing  |   |
|   |   STOPS immediately.                                                |   |
|   | - CRITICAL: An Allow Network Rule bypasses Application Rules!       |   |
|   +---------------------------------------------------------------------+   |
|          | (If no Network Rule match)                                       |
|          v                                                                  |
|   +---------------------------------------------------------------------+   |
|   | STEP 3: Application Rules (Layer 7 Filtering)                       |   |
|   | - Evaluates HTTP, HTTPS, MSSQL, Target FQDNs, URLs, Web Categories. |   |
|   | - Terminates on first match (Allow or Deny).                        |   |
|   +---------------------------------------------------------------------+   |
|          | (If no Application Rule match)                                   |
|          v                                                                  |
|   [ FINAL RESULT: Implicit Default Deny (Packet Dropped) ]                  |
+-----------------------------------------------------------------------------+

Detailed Processing Mechanics

1. DNAT Rules (Inbound Translation):
   • Inbound packets arriving at a firewall public IP are evaluated against DNAT rules first.
   • When a match is found, the firewall translates the external destination IP and port to the internal private IP and port of the target backend workload.
   • Implicit Allow: A matching DNAT rule generates an implicit network allow rule. You do not need to author a corresponding Network Rule or Application Rule to permit the translated packet.
2. Network Rules (L3/L4 Protocol & Port Filtering):
   • Evaluates source IP/CIDR/IP Groups, protocols (TCP, UDP, ICMP, Any), destination ports, and destination IP addresses, Service Tags, or FQDNs.
   • Terminating Action: As soon as a packet matches a Network Rule (whether Allow or Deny), the decision is final. Processing terminates instantly.
   • The Bypass Pitfall: If an engineer creates a Network Rule permitting outbound TCP port 80/443 to * (Any), all web traffic will match the Network Rule and be permitted immediately. The packet will never reach the Application Rules, completely bypassing FQDN filtering, URL filtering, and web category restrictions.
3. Application Rules (L7 Content Filtering):
   • Traffic that does not match any Network Rule is evaluated by the transparent proxy application engine.
   • Supports HTTP (80), HTTPS (443), and MSSQL (1433).
   • Matches against Target FQDNs (e.g., *.microsoft.com), Web Categories (e.g., ComputersAndTechnology), or specific URL paths (when TLS Inspection is active).
4. Implicit Default Deny:
   • Any packet that traverses DNAT, Network, and Application rule tiers without triggering an explicit Allow rule is silently dropped by the platform's default deny posture.

Rule Collection Groups, Collections, and Priorities

Firewall Policies organize rules into a three-tiered hierarchy:

• Rule Collection Groups (RCG): Container for rule collections (e.g., DefaultNetworkRuleCollectionGroup, DefaultApplicationRuleCollectionGroup). RCGs have a priority ranging from 100 to 65,000.
• Rule Collections: Group of individual rules within an RCG sharing an action type (Allow or Deny) and a priority (100 to 65,000).
• Individual Rules: The actual packet matching parameters (source, destination, protocol, ports).

[!NOTE] Priority Evaluation Order: Lower integer values represent higher priority (e.g., Priority 100 executes before Priority 200). Within the same rule type, evaluation proceeds strictly in ascending priority order.

4. Threat Intelligence & Azure Firewall Premium Features

Azure Firewall integrates automated threat telemetry and advanced next-generation inspection capabilities to secure complex hybrid and cloud-native topologies.

Threat Intelligence Engine

Microsoft continuously feeds threat data gathered from the Microsoft Cyber Defense Operations Center and trillions of daily global telemetry signals into the Azure Firewall engine.

• Operational Modes:
  • Off: Threat Intelligence filtering is disabled.
  • Alert only: Logs traffic to/from known malicious IP addresses and domains in Azure Monitor (Log Analytics) without dropping packets.
  • Alert and Deny: Logs and automatically drops all communication with known malicious Command & Control (C2) servers, botnets, and malware drop sites.
• FQDN / IP Allowlisting: Administrators can configure explicit bypass rules for false positives or approved security penetration testing tools.

+-----------------------------------------------------------------------------+
|                  AZURE FIREWALL PREMIUM DEEP PACKET INSPECTION              |
|                                                                             |
|   Workload VM                    Azure Firewall Premium           Destination
|   (10.1.0.4)                         (10.100.0.4)                (External)
|        |                                  |                           |
|        |--- (1) HTTPS Client Hello ------>|                           |
|        |<-- (2) Firewall CA Cert Handshake|                           |
|        |    [TLS Session 1 Established]   |                           |
|        |                                  |--- (3) HTTPS Server Hello|
|        |                                  |<-- (4) Origin Cert Handsh|
|        |                                  |   [TLS Session 2 Estab'd] |
|        |                                  |                           |
|        |--- (5) Encrypted Payload ------->|                           |
|        |                                  | (6) Decrypts Payload      |
|        |                                  | - IDPS Signature Matching |
|        |                                  | - Full URL Path Filter    |
|        |                                  | - Web Category Check      |
|        |                                  | (7) Re-encrypts Payload   |
|        |                                  |                           |
|        |                                  |--- (8) Clean Payload ---->|
+-----------------------------------------------------------------------------+

Premium Capabilities: TLS Inspection

Traditional firewalls cannot inspect encrypted HTTPS traffic (TLS 1.2 / TLS 1.3), rendering Layer 7 inspection blind to hidden malware payloads and command-and-control tunnels.

• Mechanism: Azure Firewall Premium acts as an intermediate TLS Forward Proxy. It terminates the client TLS connection, decrypts the payload for deep packet inspection, and establishes a separate TLS connection to the destination web server.
• Key Vault Integration:
  • Requires an Intermediate CA Certificate generated by an enterprise internal Public Key Infrastructure (PKI) or private Certificate Authority.
  • The certificate (with private key) is securely stored in Azure Key Vault as a certificate object.
  • Azure Firewall is assigned a User-Assigned Managed Identity granted Key Vault Certificates Officer (or Get/List permissions on Secrets and Certificates) to read the private certificate.
• Client Trust: All client endpoints inside the virtual network must trust the Enterprise Root CA that signed the Intermediate CA; otherwise, end-user browsers will encounter untrusted certificate authority warnings.

Premium Capabilities: IDPS (Intrusion Detection and Prevention System)

• Signature-Based Inspection: Evaluates all network flows against over 67,000 signatures across 50+ threat categories, including exploit kits, remote code execution (RCE) attempts, coin miners, and malware command-and-control beacons.
• Modes: Configurable as Disabled, Alert, or Alert and Deny.
• Bypass Configurations: Allows administrators to define bypass rules matching specific source IPs, destination IPs, ports, and protocols to prevent inspection overhead on trusted internal database replication links.

URL Filtering & Web Categories

• Standard SKU: Can only filter by destination domain/FQDN (e.g., contoso.com or *.contoso.com).
• Premium SKU (with TLS Inspection): Can parse and filter on the complete HTTP request URI path (e.g., allowing contoso.com/public/* while blocking contoso.com/executive/payroll/*).
• Web Categories: Categorizes web endpoints into groups such as Social Networking, Gambling, High Risk, Hacking, or Streaming Media, allowing administrators to enforce broad corporate Acceptable Use Policies without manually authoring thousands of individual FQDN rules.

5. Forced Tunneling Architecture & Operational Routing

Many enterprise compliance frameworks require all internet-bound traffic originating from cloud virtual networks to be routed back to an on-premises security stack (or an upstream corporate security proxy) for centralized auditing.

Forced Tunneling Mechanics

When an enterprise advertises a default route (0.0.0.0/0) via BGP over ExpressRoute or VPN Gateway, or assigns a User-Defined Route (UDR) with 0.0.0.0/0 pointing to an on-premises gateway, standard Azure Firewall deployments will break due to asymmetric routing of platform management traffic.

+-----------------------------------------------------------------------------+
|                     FORCED TUNNELING ROUTING TOPOLOGY                       |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | Spoke Subnet (10.1.0.0/24)                                          |   |
|   | - UDR: 0.0.0.0/0 -> Next Hop: Virtual Appliance (10.100.0.4)        |   |
|   +---------------------------------------------------------------------+   |
|                                  |                                          |
|                                  v                                          |
|   +---------------------------------------------------------------------+   |
|   | AzureFirewallSubnet (10.100.0.0/26) [Data Plane: 10.100.0.4]        |   |
|   | - UDR: 0.0.0.0/0 -> Next Hop: Virtual Network Gateway / ExpressRoute|   |
|   | - SNATs customer payload and forwards to On-Premises Firewalls      |   |
|   +---------------------------------------------------------------------+   |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   | AzureFirewallManagementSubnet (10.100.0.64/26)                      |   |
|   | - Dedicated Management Public IP                                    |   |
|   | - System Route: 0.0.0.0/0 -> Next Hop: Internet                     |   |
|   | - Isolated: Carries Microsoft health probes, logs, diagnostic sync  |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Deployment Rules for Forced Tunneling:

1. Pre-Creation Prerequisite: AzureFirewallManagementSubnet must be defined during the initial creation of the firewall. You cannot convert an existing standard Azure Firewall to a Forced Tunneling firewall without deleting and redeploying the firewall resource.
2. Routing Isolation:
   • AzureFirewallSubnet has a UDR routing 0.0.0.0/0 to the VPN/ExpressRoute gateway or NVA.
   • AzureFirewallManagementSubnet must maintain a direct path to the public Internet (0.0.0.0/0 -> Internet). Under no circumstances should management traffic be routed through on-premises paths, as doing so introduces latency and packet inspection that disrupts Azure control-plane health heartbeats.
3. SNAT Behavior: When customer traffic traverses Azure Firewall in a forced tunneling setup, outbound SNAT uses the firewall's private IP address rather than a public IP, ensuring seamless private routing across hybrid ExpressRoute circuits.