Azure Firewall Explained: How It Works and When to Use It
Azure Firewall is a cornerstone of modern cloud network security, acting as a safeguard for Azure Virtual Network resources. It represents a fully stateful, cloud native firewall service, ensuring high availability without the need for additional configurations or load balancers. Azure Firewall’s design allows it to scale automatically, adapting to fluctuating network traffic and ensuring that your security posture is never compromised by traffic peaks.
You can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. Azure Firewall uses a static public IP address for your virtual network resources allowing outside firewalls to identify traffic originating from your virtual network. The service is fully integrated with Azure Monitor for logging and analytics.
What are Azure Firewall Features
The service boasts a suite of features aimed at providing comprehensive network protection:
Built-in High Availability: Azure Firewall eliminates the need for external load balancers through its inherently high availability architecture, ensuring that your firewall is always operational without any additional setup.
Unrestricted Cloud Scalability: It dynamically scales with your network traffic, meaning that your security measures scale with your needs without necessitating upfront peak traffic budgeting.
Application & Network Traffic Filtering Rules: Azure Firewall allows the creation of detailed allow or deny rules based on source and destination IP addresses, ports, and protocols, across multiple subscriptions and virtual networks. Its fully stateful nature ensures legitimate packets for various connections are correctly identified and logged.
FQDN Filtering & Tags: Outbound HTTP/S traffic can be limited to specified fully qualified domain names (FQDNs), including support for wildcards, without requiring SSL termination. Additionally, FQDN tags simplify the process of allowing traffic from well-known Azure services, like Windows Update, through the firewall.
SNAT & DNAT Support: Azure Firewall employs Source Network Address Translation (SNAT) for all outbound traffic, translating virtual network IP addresses to a static public IP. For inbound traffic, Destination Network Address Translation (DNAT) ensures that network traffic is correctly routed and filtered to private IP addresses within your virtual networks.
Azure Monitor Integration: All firewall events are integrated with Azure Monitor, offering robust logging and analytics capabilities, including the option to archive logs to a storage account, stream events to Event Hub, or send them to Log Analytics for detailed analysis.
Known Azure Firewall Issues & Mitigations
Despite its robustness, Azure Firewall has known challenges, such as conflicts with Azure Security Center’s Just-in-Time (JIT) access feature, limitations with hub and spoke models using global peering, and issues with network filtering rules for non-TCP/UDP protocols due to SNAT limitations with the Standard Load Balancer. Additionally, there are certain constraints around moving firewalls to different resource groups or subscriptions and limitations on port ranges in network and application rules. Many of these issues have workarounds, such as reconfiguring network architecture or awaiting future software updates for enhanced support.
ISSUE | DESCRIPTION | MITIGATION |
Conflict with Azure Security Center (ASC) Just-in-Time (JIT) | If a virtual machine is accessed using JIT, and is in a subnet with a user-defined route that points to Azure Firewall as a default gateway, ASC JIT doesn’t work. This is a result of asymmetric routing – a packet comes in via the virtual machine public IP (JIT opened the access), but the return path is via the firewall, which drops the packet because no session is established on the firewall. | To work around this issue, place the JIT virtual machines on a separate subnet that doesn’t have a user-defined route to the firewall. |
Hub-and-spoke with global peering not supported | Using the hub and spoke model, where the hub and firewall are deployed in one Azure region, with the spokes in another Azure region. Connections to the hub via Global VNet Peering are not supported. | This is by design. For more information, see Azure subscription and service limits, quotas, and constraints |
Network filtering rules for non-TCP/UDP protocols (for example ICMP) don’t work for Internet-bound traffic | Network filtering rules for non-TCP/UDP protocols don’t work with SNAT to your public IP address. Non-TCP/UDP protocols are supported between spoke subnets and VNets. | Azure Firewall uses the Standard Load Balancer, which doesn’t support SNAT for IP protocols today. We are exploring options to support this scenario in a future release. |
Missing PowerShell/CLI support for ICMP | Azure PowerShell and CLI don’t support ICMP as a valid protocol in network rules. | It is still possible to use ICMP as a protocol via the portal and the REST API. We are working to add ICMP in PowerShell and CLI soon. |
FQDN tags require a protocol: port to be set | Application rules with FQDN tags require port: protocol definition. | You can use https as the port: protocol value. We are working to make this field optional when FQDN tags are used. |
Moving a firewall between resource groups/subscriptions not supported | Azure Firewall cannot be moved to a different resource group or subscription. | Supporting this functionality is on our road map. To move a firewall to a different resource group or subscription, you must delete the current instance and recreate it in the new resource group or subscription. |
Port range limits in rules | Ports are limited to 64,000 as high ports are reserved for management and health probes. | We are working to relax this limitation. |
FAQs about Azure Firewalls
What is Azure Firewall used for?
Azure Firewall is used to control and protect inbound, outbound, and east–west traffic for Azure Virtual Network (VNet) resources by enforcing centralized application and network rules, while logging activity for monitoring and investigations.
Is Azure Firewall stateful or stateless?
Azure Firewall is stateful, meaning it tracks connection sessions so return traffic for legitimate connections is allowed and logged appropriately.
Does Azure Firewall require a load balancer for high availability?
No. Azure Firewall is designed with built-in high availability, so you don’t need to deploy or configure additional load balancers to make it highly available.
Does Azure Firewall scale automatically?
Yes. Azure Firewall is designed to scale automatically to handle increases in network traffic, helping maintain consistent protection during traffic spikes.
Can Azure Firewall filter traffic by domain name (FQDN)?
Yes. Azure Firewall supports FQDN filtering for outbound HTTP/S traffic (including wildcard support) and also provides FQDN tags to simplify allowing traffic to common Azure services.
What’s the difference between network rules and application rules in Azure Firewall?
Network rules filter traffic based on IP addresses, ports, and protocols.
Application rules filter outbound web traffic using domain names (FQDNs) and allow more application-aware control for HTTP/S destinations.
Does Azure Firewall support SNAT and DNAT?
Yes. Azure Firewall supports:
SNAT for outbound traffic (translating private IPs to a static public IP), and
DNAT for inbound traffic (mapping public destinations to private IPs inside VNets).
Where do Azure Firewall logs go?
Azure Firewall integrates with Azure Monitor, and logs can be sent to Log Analytics, Event Hub, or a Storage Account for analysis, streaming, or archiving.
Are there known limitations with Azure Firewall?
Yes. Common limitations include challenges with certain routing scenarios (e.g., JIT + UDR asymmetric routing), specific architecture constraints (e.g., global peering hub-and-spoke), and protocol/rule limitations for some non-TCP/UDP internet-bound traffic often with documented workarounds.
