Azure Firewall

Azure Firewall is a fully stateful, managed firewall-as-a-service that provides network and application-level traffic filtering for Azure virtual networks. It is deployed in a dedicated subnet (AzureFirewallSubnet) within a virtual network and can be associated with multiple virtual networks via hub-and-spoke topology using VNet peering. It offers built-in high availability, auto-scaling, and integration with Azure Monitor for logging and analytics.

Before Azure Firewall, customers used third-party network virtual appliances (NVAs) or Network Security Groups (NSGs) for traffic filtering. NSGs are stateless or stateful only at the subnet/NIC level and cannot perform application-level inspection (FQDN filtering). NVAs require manual management, scaling, and patching. Azure Firewall fills the gap by providing a PaaS solution with:

Azure Firewall is deployed as a virtual appliance in a dedicated subnet (AzureFirewallSubnet) with a /26 subnet mask minimum. It has at least one public IP address for inbound traffic and can have additional public IPs for outbound SNAT. The firewall processes traffic based on a set of rules collected into rule collections, which are grouped into rule collection groups. The rule processing order is: 1. DNAT rules – Inbound traffic destined to the firewall's public IP is translated to a private IP. 2. Network rules – Non-HTTP/HTTPS traffic (or traffic not matched by application rules) is evaluated against network rules (source, destination, port, protocol). 3. Application rules – Outbound HTTP/HTTPS traffic is evaluated against application rules (FQDN filtering). 4. Network rules (again) – Traffic not matched by application rules falls back to network rules.

Traffic that matches no rule is denied by default (implicit deny). The firewall maintains a connection table for stateful tracking. For TCP, it tracks SYN, SYN-ACK, ACK, and FIN/RST. For UDP, it tracks source/destination IP and port pairs and times out after 4 minutes of inactivity (default). ICMP is tracked similarly.

Azure Firewall is primarily configured via the Azure portal, Azure CLI, PowerShell, or ARM templates. Common CLI commands:

Create a firewall:

az network firewall create \
    --name MyFirewall \
    --resource-group MyRG \
    --location eastus \
    --sku AZFW_VNet \
    --vnet-name MyVNet \
    --public-ip-addresses MyPublicIP

Add a network rule collection:

az network firewall network-rule create \
    --firewall-name MyFirewall \
    --resource-group MyRG \
    --collection-name MyNetColl \
    --priority 200 \
    --action Allow \
    --source-addresses 10.0.0.0/16 \
    --protocols TCP \
    --destination-addresses 192.168.1.0/24 \
    --destination-ports 80,443

Add an application rule collection:

az network firewall application-rule create \
    --firewall-name MyFirewall \
    --resource-group MyRG \
    --collection-name MyAppColl \
    --priority 300 \
    --action Allow \
    --source-addresses 10.0.0.0/16 \
    --protocols Http=80 Https=443 \
    --target-fqdns *.microsoft.com

Verify rules:

az network firewall list --resource-group MyRG --output table
az network firewall network-rule list --firewall-name MyFirewall --resource-group MyRG

Diagnostic logs: Enable via Azure Monitor diagnostic settings. Logs include:

Azure Firewall can handle up to 30 Gbps throughput (Standard SKU). It automatically scales based on CPU usage. Connection limits are high (millions of concurrent connections). For production, deploy with Availability Zones for resilience. For very high throughput requirements, consider Azure Firewall Premium (up to 100 Gbps) or multiple firewalls in a scale-out design.

AZ-104 tests your ability to:

#### 1. Create a Virtual Network with Subnets Create a VNet with two subnets: one for workload VMs (e.g., 10.0.1.0/24) and one for the firewall (AzureFirewallSubnet, 10.0.0.0/26). Ensure the firewall subnet is named exactly 'AzureFirewallSubnet'.

#### 2. Create a Public IP for the Firewall Create a Standard SKU public IP address. It must be in the same region as the firewall. For high availability, you can create multiple public IPs (up to 250).

#### 3. Deploy Azure Firewall In the Azure portal, search for 'Firewall' and create a new instance. Select the VNet and public IP. Choose SKU: Standard or Premium. Enable threat intelligence mode (Alert or Alert and Deny). Configure availability zones if needed.

#### 4. Configure Network Rules Add network rules to allow inbound or outbound traffic based on IP addresses, ports, and protocols. For example, allow outbound HTTP/HTTPS to any IP: Allow | Any | 10.0.1.0/24 | 80,443 | TCP | *.

#### 5. Configure Application Rules Add application rules for outbound HTTP/HTTPS traffic based on FQDNs. For example, allow access to *.microsoft.com.

#### 6. Configure DNAT Rules Add DNAT rules to translate inbound traffic on the firewall's public IP to a private IP inside the VNet. For example, map public IP:3389 to 10.0.1.4:3389 for RDP.

#### 7. Route Traffic to the Firewall Create a route table with a default route (0.0.0.0/0) with next hop set to the firewall's private IP. Associate the route table with the workload subnet(s). For inbound traffic, the firewall's public IP is the entry point.

#### 8. Enable Diagnostic Logs In the firewall's diagnostic settings, send logs to Log Analytics workspace, storage account, or Event Hubs. Monitor for denied connections.

#### 9. Test Connectivity From a VM in the workload subnet, test outbound connectivity (e.g., curl www.microsoft.com). Verify that allowed traffic passes and denied traffic is blocked. Check firewall logs.

#### Scenario 1: Enterprise Hub-and-Spoke with Forced Tunneling A multinational corporation has multiple spoke VNets in Azure, each hosting application tiers. They need to inspect all outbound internet traffic and route it through an on-premises firewall for compliance. They deploy Azure Firewall in a hub VNet with forced tunneling enabled. The firewall's default route points to the on-premises firewall via VPN/ExpressRoute. All spoke VNets peer with the hub and use the firewall as the next hop for internet traffic. This ensures all outbound traffic is logged and inspected. Common misconfiguration: forgetting to create the AzureFirewallManagementSubnet for forced tunneling, or setting the default route incorrectly causing asymmetric routing.

#### Scenario 2: E-commerce Platform with DNAT and Application Filtering An e-commerce company runs web servers in a VNet. They want to allow inbound HTTPS traffic to the web servers and restrict outbound traffic from the app servers to only a few FQDNs (e.g., payment gateway, database SaaS). They deploy Azure Firewall with DNAT rules to map public IP:443 to web server private IP:443. They create application rules to allow outbound FQDNs for the app servers. They also enable threat intelligence to block known malicious IPs. Performance considerations: with high traffic, they monitor SNAT port usage and add multiple public IPs to avoid port exhaustion. Misconfiguration: using network rules instead of application rules for FQDN filtering, which would require IP addresses that may change.

#### Scenario 3: Multi-Region Deployment with Azure Firewall Manager A global SaaS provider has VNets in multiple Azure regions. They need consistent firewall policies across all regions. They use Azure Firewall Manager to create a global firewall policy with parent and child policies. Each regional firewall inherits the parent policy and can have region-specific overrides. This simplifies management and ensures compliance. Common issues: policy inheritance conflicts when child policies override parent rules incorrectly; monitoring logs centrally from all firewalls.

Objective 4.5: Configure and manage Azure Firewall – This includes deploying, configuring rules, managing policies, and troubleshooting. The exam tests your ability to choose between Azure Firewall and other security services.

Common Wrong Answers: 1. Using NSG for FQDN filtering – Candidates assume NSGs can filter by domain name. Reality: NSGs only filter by IP address, port, and protocol. Application rules in Azure Firewall are required for FQDN filtering. 2. Placing Azure Firewall in any subnet – Candidates think any subnet works. Reality: The subnet must be named 'AzureFirewallSubnet' and have a /26 or larger mask. 3. Forgetting SNAT behavior – Candidates assume outbound traffic retains the VM's private IP. Reality: Azure Firewall SNATs outbound traffic to the firewall's public IP by default. 4. Assuming rule priority is global – Candidates think rules are evaluated in order they are created. Reality: Rule collection priority (1-65535) determines evaluation order. Lower number = higher priority.

Specific Numbers and Terms: - AzureFirewallSubnet size: /26 (64 addresses). - Rule collection priority range: 100-65000 (recommended). - Default SNAT port limit: 1,024 per public IP per destination IP:port. - Maximum throughput: Standard 30 Gbps, Premium 100 Gbps. - SLA: 99.95% with no zones, 99.99% with zones. - Diagnostic log categories: AzureFirewallApplicationRule, AzureFirewallNetworkRule, AzureFirewallDnsProxy.

Edge Cases: - Forced tunneling requires an additional subnet named 'AzureFirewallManagementSubnet' (minimum /26). - Application rules only work for TCP/80 and TCP/443. For other ports, use network rules. - ICMP can be allowed via network rules, but by default it is blocked. - Firewall cannot be moved between resource groups or subscriptions after creation. - When using multiple public IPs, outbound SNAT traffic is distributed among them (not per session).

How to Eliminate Wrong Answers: - If the question mentions filtering by FQDN, the answer must involve Azure Firewall application rules, not NSG or network rules. - If the question mentions centralized policy management across multiple firewalls, think Azure Firewall Manager. - If the question mentions threat intelligence, think Azure Firewall Premium (or Standard with threat intel enabled). - If the question mentions high throughput (>30 Gbps), think Azure Firewall Premium or multiple firewalls.

- Azure Firewall vs Network Security Groups (NSGs) - Scope: Centralized, VNet-wide vs subnet/NIC-level. - Statefulness: Stateful for all protocols vs stateful for TCP/UDP (stateless option available). - FQDN filtering: Yes (application rules) vs No (only service tags). - Threat intelligence: Yes vs No. - NAT: Yes (DNAT/SNAT) vs No. - Logging: Rich diagnostic logs vs NSG flow logs. - Cost: Higher cost vs lower cost.

- Azure Firewall vs Third-Party NVAs (e.g., Palo Alto, Fortinet) - Management: Azure-native vs vendor-specific. - Scaling: Auto-scaling vs manual scaling. - Features: Deep packet inspection, advanced threat prevention vs basic to advanced. - Licensing: Pay-as-you-go (included in Azure cost) vs bring-your-own-license. - Integration: Tight with Azure services vs may require additional configuration. - Performance: Up to 30/100 Gbps vs up to hundreds of Gbps.

- Azure Firewall Standard vs Premium - TLS inspection: No vs Yes. - IDPS: No vs Yes. - Web categories: No vs Yes. - Threat intelligence: Basic vs Advanced. - Throughput: Up to 30 Gbps vs up to 100 Gbps. - Cost: Lower vs Higher.

- Q: What is the difference between Azure Firewall and Azure Firewall Manager? A: Azure Firewall is the actual firewall instance. Azure Firewall Manager is a management tool that allows you to create, enforce, and monitor firewall policies across multiple Azure Firewall instances. You can use Firewall Manager to apply consistent policies globally.

- Q: Can Azure Firewall filter traffic between VNets (east-west)? A: Yes. If you route traffic between VNets through the firewall (e.g., via VNet peering and user-defined routes), the firewall can inspect and filter east-west traffic. This is a common pattern for security segmentation.

- Q: Does Azure Firewall support ICMP? A: Yes, but by default it is blocked. You must create a network rule to allow ICMP. For example, allow ICMP from source to destination.

- Q: How do I troubleshoot connectivity issues through Azure Firewall? A: Enable diagnostic logs and send them to Log Analytics. Use queries to view denied connections. Also, check route tables to ensure traffic is directed to the firewall. Verify that the firewall's public IP is reachable and that DNAT rules are correctly configured.

- Q: Can I use Azure Firewall with Azure Virtual WAN? A: Yes. You can deploy Azure Firewall as a secured virtual hub in Azure Virtual WAN. This allows you to use the firewall for traffic inspection across all branches and VNets connected to the Virtual WAN.

- Q: What is the default rule priority? A: There is no default priority. You must assign a priority (100-65000) to each rule collection. A lower number means higher priority.

- Q: Can I have multiple Azure Firewalls in the same VNet? A: No. You can only have one Azure Firewall per VNet. If you need more throughput or redundancy, you can deploy multiple firewalls in different VNets and use Azure Firewall Manager.

- Q: Does Azure Firewall support custom DNS? A: Yes. You can configure DNS proxy to forward DNS requests to custom DNS servers. This is required for FQDN filtering in network rules.

- Q: You need to filter outbound HTTPS traffic from Azure VMs based on fully qualified domain names (FQDNs). Which Azure service should you use? A: Azure Firewall with application rules. NSGs cannot filter by FQDN; they only filter by IP address. Azure Firewall application rules allow you to specify allowed FQDNs for HTTP/HTTPS traffic.

- Q: You are deploying Azure Firewall and need to ensure high availability. Which two actions should you take? A: Deploy the firewall in an availability zone (or across multiple zones) and use at least two public IPs. Availability zones provide resilience against datacenter failures, and multiple public IPs help avoid SNAT port exhaustion.

- Q: A user reports that outbound internet traffic from VMs in a spoke VNet is failing. The VNet is peered to a hub VNet with Azure Firewall. What is the most likely cause? A: Missing route table on the spoke subnet to direct traffic to the firewall's private IP. Azure Firewall does not automatically route traffic; you must create a user-defined route with next hop as the firewall's private IP.

- Q: You need to forward all outbound internet traffic from Azure VMs to an on-premises firewall for inspection. Which Azure Firewall feature should you configure? A: Forced tunneling. This requires an additional subnet (AzureFirewallManagementSubnet) and a default route (0.0.0.0/0) pointing to the on-premises firewall.

- Q: What is the minimum subnet size required for Azure Firewall? A: /26 (64 IP addresses). The subnet must be named 'AzureFirewallSubnet'.

- Q: You have multiple Azure Firewall instances across different regions. You need to enforce a common set of firewall rules. What should you use? A: Azure Firewall Manager. It allows you to create a global firewall policy that can be applied to all firewalls, with optional local overrides.

- Q: Which Azure Firewall SKU supports TLS inspection? A: Premium SKU. Standard SKU does not support TLS inspection.

- Q: A VM behind Azure Firewall cannot connect to an external HTTPS website. The firewall has a network rule allowing outbound TCP/443 to any IP. What could be the issue? A: The network rule might be missing, or the traffic might be matched by an application rule that denies the FQDN. Check application rules first, as they are evaluated before network rules for HTTP/HTTPS traffic.

A global financial services company has multiple Azure subscriptions, each containing application VNets (spokes). Compliance requires that all outbound internet traffic be inspected by an on-premises firewall. They deploy Azure Firewall in a central hub VNet with forced tunneling enabled. The firewall is configured with a default route (0.0.0.0/0) pointing to the on-premises firewall via a site-to-site VPN or ExpressRoute. An additional subnet, AzureFirewallManagementSubnet, is created for management traffic. All spoke VNets peer with the hub, and each spoke subnet has a route table with a default route pointing to the firewall's private IP. This architecture ensures that all outbound traffic flows through the on-premises firewall, meeting compliance. Common misconfigurations include: forgetting to create the management subnet, incorrect route propagation causing asymmetric routing, or not allowing necessary traffic (e.g., DNS) through the firewall.

An online retailer runs web servers in a VNet. They need to allow inbound HTTPS traffic from the internet to the web servers and restrict outbound traffic from app servers to only a few external services (e.g., payment gateway, email service). They deploy Azure Firewall with DNAT rules to map public IP:443 to the web server's private IP:443. For outbound traffic, they create application rules allowing specific FQDNs (e.g., api.payment.com, smtp.email.com) from the app server subnet. They also enable threat intelligence to block known malicious IPs. Performance considerations: with high traffic volumes (e.g., Black Friday), they must monitor SNAT port usage. They add multiple public IPs to the firewall to distribute the load. A common issue is SNAT port exhaustion, which manifests as intermittent connectivity failures. They use Azure Monitor alerts to notify when port usage exceeds 80%.

A global SaaS provider has VNets in multiple Azure regions. They need consistent firewall policies across all regions but allow regional variations. They use Azure Firewall Manager to create a global firewall policy (parent policy) that includes common rules (e.g., block known malicious IPs, allow Azure services). Each regional firewall has a child policy that inherits from the parent and adds region-specific rules (e.g., allow local regulatory IPs). This simplifies management and ensures compliance. Common issues: policy inheritance conflicts when child policies override parent rules unintentionally; troubleshooting becomes complex when logs from multiple firewalls need to be correlated. They use Azure Sentinel for centralized log analysis.