Planning and Implementing Azure Firewall: A Comprehensive Guide

Introduction: Why Network Security Matters in the Cloud

In the early days of cloud computing, many organizations operated under the assumption that their cloud provider handled all security concerns. We now know that security is a shared responsibility. While Microsoft secures the physical infrastructure and the virtualization layer, you are responsible for securing the traffic flowing in, out, and within your virtual networks. When you expose services to the public internet, or even when you need to strictly control internal traffic between subnets, the network perimeter becomes your primary line of defense.

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a stateful firewall as a service (FWaaS), meaning it keeps track of the state of active connections and makes decisions based on the context of the traffic flow. Unlike traditional network appliances that require you to manage hardware, updates, and scaling, Azure Firewall is fully managed by Microsoft, allowing you to focus on defining security policies rather than maintaining physical or virtual infrastructure.

This lesson explores the architecture, planning, deployment, and management of Azure Firewall. Whether you are building a landing zone for enterprise applications or securing a simple web front-end, understanding how to control traffic flows is essential for maintaining a secure posture. We will move beyond the basics to look at policy management, threat intelligence, and how to structure your network to ensure maximum protection without sacrificing performance.

Understanding Azure Firewall Architecture

To effectively use Azure Firewall, you must first understand how it fits into your network topology. Azure Firewall is typically deployed within a dedicated subnet inside your Virtual Network (VNet). Because it is a stateful service, it inspects packets and allows or denies traffic based on rules you define.

Deployment Models

There are two primary ways to deploy Azure Firewall:

1. Standalone Deployment: You place the firewall directly into the VNet that contains your workloads. This is common for smaller environments where a simple hub-and-spoke model is not yet necessary.
2. Hub-and-Spoke Deployment: This is the industry-standard architecture for enterprise environments. You create a central "Hub" VNet that contains the Azure Firewall, and multiple "Spoke" VNets containing your applications are peered to this hub. All traffic destined for the internet or between spokes is routed through the central firewall, providing a single point of control and inspection.

Callout: Stateful vs. Stateless Inspection A stateless firewall treats every packet in isolation, making decisions based only on the source, destination, and port. A stateful firewall, like Azure Firewall, tracks the state of connections. If you allow an outgoing request to a server, the firewall automatically allows the return traffic for that specific session without you needing to create a separate inbound rule. This reduces human error and keeps rule sets much smaller and easier to audit.

SKU Options

Azure Firewall comes in different tiers to meet varying requirements:

• Basic: Designed for small to medium-sized businesses. It provides essential filtering for internal and external traffic but lacks some of the advanced threat protection features.
• Standard: The traditional offering that provides Layer 3 to Layer 7 filtering. It is sufficient for most standard deployments requiring basic URL and domain filtering.
• Premium: The most advanced tier, which includes IDPS (Intrusion Detection and Prevention System), TLS inspection, and URL filtering. If you need deep packet inspection or need to decrypt HTTPS traffic to see what is inside, this is the required tier.

Planning Your Firewall Implementation

Before you deploy your first firewall, you must plan your IP addressing and routing. Azure Firewall requires a specific subnet named AzureFirewallSubnet. This subnet must be at least a /26 in size to ensure there is enough address space for the firewall instances to scale and perform maintenance tasks without interruption.

Routing Traffic

Deploying the firewall is only half the battle. You must explicitly tell your network resources to send their traffic to the firewall. This is accomplished using User-Defined Routes (UDRs).

1. Route Tables: You create a Route Table and associate it with the subnets containing your workloads.
2. Next Hop: You define a route where the address prefix 0.0.0.0/0 (representing the internet) points to the private IP address of the Azure Firewall as the "Next Hop."
3. Forced Tunneling: If you are using forced tunneling to send all internet traffic back to an on-premises network, you must ensure the firewall is configured to handle the traffic correctly so that it does not create a routing loop.

Tip: The AzureFirewallSubnet Requirement Always name your subnet AzureFirewallSubnet exactly as written. Azure looks for this specific name to deploy the firewall service. If you name it anything else, the deployment will fail. Additionally, ensure this subnet is isolated; do not deploy other virtual machines or resources into this subnet.

Implementing Azure Firewall: Step-by-Step

Let us walk through the process of deploying a Premium Azure Firewall using the Azure CLI. This approach is preferred for automation and consistency across environments.

Step 1: Create the Resource Group and VNet

First, organize your resources. We will create a VNet with a management subnet and the required firewall subnet.

# Create a resource group
az group create --name RG-Network-Security --location eastus

# Create the Virtual Network
az network vnet create \
  --name VNet-Hub \
  --resource-group RG-Network-Security \
  --address-prefix 10.0.0.0/16 \
  --subnet-name AzureFirewallSubnet \
  --subnet-prefix 10.0.1.0/26

Step 2: Deploy the Azure Firewall

Deploying the firewall involves creating a public IP address (for outbound traffic) and then the firewall resource itself.

# Create a public IP for the firewall
az network public-ip create \
  --name PIP-Firewall \
  --resource-group RG-Network-Security \
  --sku Standard

# Deploy the Firewall
az network firewall create \
  --name FW-Hub \
  --resource-group RG-Network-Security \
  --sku Premium

Step 3: Configure Firewall Policies

Modern Azure Firewall management uses "Firewall Policies" rather than the older "Classic Rules." Policies are easier to manage and can be shared across multiple firewalls.

# Create a policy
az network firewall policy create \
  --name FW-Policy-Global \
  --resource-group RG-Network-Security \
  --sku Premium

Step 4: Adding Rules to the Policy

Rules are organized into rule collections. You have three main types:

• Network Rules: Filter based on IP addresses, ports, and protocols (Layer 3/4).
• Application Rules: Filter based on FQDNs (Fully Qualified Domain Names) and HTTP/S paths (Layer 7).
• NAT Rules: Used for port forwarding, such as directing incoming traffic on a specific port to an internal server.

# Add a network rule collection
az network firewall policy rule-collection add \
  --resource-group RG-Network-Security \
  --policy-name FW-Policy-Global \
  --name Allow-DNS \
  --rule-collection-type FirewalPolicyFilterRuleCollection \
  --action Allow \
  --priority 100 \
  --rule-name Allow-DNS-Query \
  --protocols UDP \
  --source-addresses 10.0.0.0/16 \
  --destination-addresses 8.8.8.8 \
  --destination-ports 53

Best Practices for Rule Management

A common mistake is creating "Allow All" rules to fix connectivity issues, which leaves your network wide open. Follow these best practices to ensure your firewall remains effective.

1. Principle of Least Privilege

Start with a "Deny All" stance. Only create rules that specifically allow the traffic required for your services to function. If an application needs to talk to an API at api.service.com, create an application rule for that specific FQDN rather than allowing traffic to the entire *.service.com wildcard if it is not strictly necessary.

2. Use FQDN Filtering

Whenever possible, use FQDNs instead of IP addresses. IP addresses for cloud services can change frequently. If you use FQDNs, Azure Firewall handles the DNS resolution for you, ensuring your rules stay accurate even if the backend IP of a service changes.

3. Leverage Threat Intelligence

Enable Threat Intelligence-based filtering. Azure maintains a list of known malicious IP addresses and domains. By enabling this, the firewall will automatically block traffic to and from these known bad actors without you needing to manually manage a blocklist.

Callout: Managing Rule Priority Rules are processed in order of priority. Lower numbers are processed first. If you have a rule with priority 100 that allows traffic and another rule with priority 200 that denies it, the traffic will be allowed. Always keep your most specific rules at the top and your broad "deny" rules at the bottom.

4. Enable Logging and Diagnostics

A firewall that is not monitored is a blind spot. You should stream your firewall logs to a Log Analytics workspace. This allows you to run Kusto Query Language (KQL) queries to see exactly what is being blocked and why.

Example KQL query to find denied traffic:

AzureFirewallNetworkRule
| where Action == "Deny"
| project TimeGenerated, SourceIp, DestinationIp, DestinationPort, Protocol
| sort by TimeGenerated desc

Common Pitfalls and How to Avoid Them

Even experienced engineers run into issues when configuring Azure Firewall. Here are the most frequent mistakes:

Incorrect Routing

The most common issue is forgetting to update the Route Table. You can have a perfectly configured firewall, but if your virtual machines are not sending their traffic to the firewall, the traffic will bypass it entirely. Always verify your effective routes on your network interface (NIC) by checking the "Effective Routes" tab in the Azure Portal.

Asymmetric Routing

Asymmetric routing occurs when traffic enters through one path and tries to leave through another. This is common if you have VPNs or ExpressRoute connections that do not properly route traffic back through the firewall. If the return packet does not pass through the same firewall instance as the request, the stateful firewall will drop the traffic because it does not recognize the connection.

TLS Inspection Limitations

If you are using the Premium tier to inspect encrypted traffic, you must ensure your client devices trust the Certificate Authority (CA) used by the firewall. If you do not push the firewall's root certificate to your internal servers or client machines, they will see a "Certificate Not Trusted" error when trying to make HTTPS connections.

Over-complicating Rule Sets

Do not create a unique rule for every single server. Group your resources into subnets or use Azure Tags to create rules that apply to categories of resources. For example, create an "App-Tier-Access" rule that applies to all VMs tagged with Role=AppTier.

Comparison: Network Security Groups vs. Azure Firewall

A question often asked is: "Why do I need Azure Firewall if I have Network Security Groups (NSGs)?"

Use an NSG for micro-segmentation within a VNet (e.g., preventing a web server from talking to another web server in the same subnet). Use Azure Firewall for perimeter security, inspecting outbound internet traffic, and controlling traffic between different VNets or between the cloud and on-premises environments.

Advanced Feature: TLS Inspection

TLS Inspection is a powerful feature of the Azure Firewall Premium tier. When enabled, the firewall acts as a "man-in-the-middle." It terminates the SSL/TLS connection from the client, inspects the decrypted traffic for malware or sensitive data, and then initiates a new connection to the destination.

Why use TLS Inspection?

Without it, the firewall can see that traffic is going to google.com, but it cannot see the specific URL path or the payload of the request. With TLS inspection, the firewall can block specific sub-paths or inspect the content of POST requests for data exfiltration.

Implementation Steps

1. Generate a Certificate: Create a self-signed or enterprise-signed CA certificate.
2. Upload to Key Vault: Store the certificate and its private key in an Azure Key Vault.
3. Assign Identity: Grant the Azure Firewall managed identity access to the Key Vault.
4. Enable in Policy: Update your Firewall Policy to enable TLS inspection and reference the Key Vault certificate.
5. Distribute the Certificate: Deploy the public portion of the CA certificate to the Trusted Root Certification Authorities store on all your internal clients.

Warning: TLS Inspection Performance Decrypting and re-encrypting traffic is CPU-intensive. While Azure Firewall is designed to scale, performing TLS inspection on massive volumes of traffic can introduce latency. Always test your application performance after enabling this feature to ensure it meets your latency requirements.

Monitoring and Troubleshooting

Troubleshooting a firewall requires a methodical approach. When a user reports that they cannot access a resource, follow this workflow:

1. Check NSGs: Ensure an NSG isn't blocking the traffic before it even reaches the firewall.
2. Verify UDRs: Check that the subnet has a route to the firewall for the destination IP.
3. Check Firewall Logs: Use Log Analytics to see if the traffic reached the firewall and if it was "Allowed" or "Denied."
4. Review Policy Rules: Ensure the rule priority is correct and that the rule is actually enabled.
5. Test Connectivity: Use the Test-NetConnection command (in PowerShell) or nc (in Linux) from a virtual machine in the same subnet to verify if the port is open and reachable.

Using KQL for Deep Analysis

To see if your firewall is dropping traffic due to a specific rule, use the following query:

AzureFirewallNetworkRule
| where Action == "Deny"
| summarize Count = count() by RuleCollectionName, SourceIp, DestinationIp
| order by Count desc

This query helps identify "noisy" rules or common sources of blocked traffic, which is invaluable during the initial "tuning" phase after a new deployment.

Industry Standards and Compliance

For organizations in regulated industries (finance, healthcare, government), Azure Firewall is a critical tool for meeting compliance requirements like PCI-DSS or HIPAA.

• Auditability: Every rule change is logged in the Azure Activity Log. You can see who created a rule, when they did it, and what the rule contains. This provides an immutable audit trail.
• Centralized Governance: By using Azure Policy, you can enforce that all VNets must have a route to a central firewall, preventing "shadow IT" deployments that bypass security controls.
• Intrusion Detection: Using the IDPS features in the Premium tier allows you to satisfy requirements for active monitoring of network traffic for known attack signatures.

Key Takeaways for Successful Implementation

1. Start with the Architecture: Choose between standalone or hub-and-spoke early. The hub-and-spoke model is almost always the better choice for long-term scalability and centralized management.
2. Prioritize Policy Management: Move away from classic rules and use Firewall Policies. They offer better reusability, hierarchical management, and easier auditing.
3. Master the Routing: Your firewall is useless if traffic doesn't pass through it. Always validate your Route Tables and verify that your subnets are correctly associated with the intended routes.
4. Use Threat Intelligence: Enable built-in threat intel features immediately. It is an easy win that provides significant protection against known malicious actors without adding complexity to your rule sets.
5. Monitor Everything: You cannot secure what you cannot see. Set up Log Analytics, configure diagnostic settings, and build dashboards to visualize your traffic patterns.
6. Test Before Production: Always test your rule changes in a staging environment. A misconfigured firewall rule can easily bring down critical production applications.
7. Keep it Simple: Avoid overly complex rule sets. If you find yourself creating hundreds of individual rules, look for ways to group traffic by FQDN tags, IP groups, or application categories.

By following these principles, you turn your Azure Firewall from a simple "blocker" into a sophisticated tool that provides visibility, control, and security for your cloud environment. Remember that network security is an iterative process; as your applications evolve, so too must your firewall policies. Regularly review your logs, prune unused rules, and stay updated on the latest security features released by Microsoft.