Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It's a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. You can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks.
For a detailed list of Azure Firewall features, see Azure Firewall features.
Azure Firewall can be deployed on any virtual network. However, it's typically deployed on a central virtual network in a hub-and-spoke model, with other virtual networks peered to it. The default route from the peered virtual networks is set to point to this central firewall virtual network. While global virtual network peering is supported, it isn't recommended due to potential performance and latency issues across regions. For optimal performance, deploy one firewall per region.
This model allows centralized control over multiple spoke VNets across different subscriptions and offers cost savings by avoiding the need to deploy a firewall in each virtual network. Cost savings should be evaluated against the associated peering costs based on traffic patterns.
Azure Firewall can be deployed using the Azure portal, PowerShell, REST API, or templates. For step-by-step instructions, see Tutorial: Deploy and configure Azure Firewall using the Azure portal.
Azure Firewall uses rules and rule collections. A rule collection is a set of rules with the same order and priority. Rule collections are executed in priority order. DNAT rule collections have higher priority than network rule collections, which in turn have higher priority than application rule collections. All rules are terminating.
There are three types of rule collections:
- Application rules: Configure fully qualified domain names (FQDNs) that can be accessed from a virtual network.
- Network rules: Configure rules with source addresses, protocols, destination ports, and destination addresses.
- NAT rules: Configure DNAT rules to allow incoming Internet or intranet (preview) connections.
For more information, see Configure Azure Firewall rules.
Azure Firewall integrates with Azure Monitor for viewing and analyzing logs. Logs can be sent to Log Analytics, Azure Storage, or Event Hubs and analyzed using tools like Log Analytics, Excel, or Power BI. For more information, see Tutorial: Monitor Azure Firewall logs.
Azure Firewall is a managed, cloud-based network security service that protects virtual network resources. It's a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. It's preintegrated with third-party security-as-a-service (SECaaS) providers to enhance security for virtual network and branch Internet connections. For more information, see Azure network security.
Application Gateway WAF provides centralized inbound protection for web applications against common exploits and vulnerabilities. Azure Firewall provides inbound protection for non-HTTP/S protocols (for example, RDP, SSH, FTP), outbound network-level protection for all ports and protocols, and application-level protection for outbound HTTP/S.
Azure Firewall complements NSGs to provide better "defense-in-depth" network security. NSGs offer distributed network layer traffic filtering to limit traffic within virtual networks in each subscription. Azure Firewall provides centralized, fully stateful network and application-level protection across subscriptions and virtual networks.
Azure Firewall is a managed service with multiple protection layers, including platform protection with NIC-level NSGs (not viewable). Subnet-level NSGs aren't required on the AzureFirewallSubnet and are disabled to prevent service interruptions.
Private endpoints are a component of Private Link, a technology that allows to interact with Azure PaaS services using private IP addresses instead of public ones. Azure Firewall can be used to prevent access to public IP addresses, hence avoiding data exfiltration to Azure services not leveraging Private Link, as well as to implement zero-trust policies by defining who in your organization needs to access those Azure PaaS services, since Private Link per default opens up network access for your whole corporate network.
The right design to inspect traffic to private endpoints with Azure Firewall will depend on your network architecture, you can find more details in the article Azure Firewall scenarios to inspect traffic destined to a private endpoint.
Virtual Network service endpoints are an alternative to Private Link to control network access to Azure PaaS services. Even if the client still uses public IP addresses to access the PaaS service, the source subnet is made visible so that the destination PaaS service can implement filter rules and restrict access on a per-subnet basis. You can find a detailed comparison between both mechanisms in Compare Private Endpoints and Service Endpoints.
Azure Firewall application rules can be used to make sure that no data exfiltration to rogue services takes place, and to implement access policies with an increased granularity beyond the subnet level. Usually, virtual network service endpoints need to be enabled in the subnet of the client that will connect to an Azure service. However, when inspecting traffic to service endpoints with Azure Firewall, you need to enable the corresponding service endpoint in the Azure Firewall subnet instead and disable them on the subnet of the actual client (usually a spoke virtual network). This way you can use Application Rules in Azure Firewall to control to which Azure services your Azure workloads will have access to.
For pricing details, see Azure Firewall Pricing.
For service limits, see Azure subscription and service limits, quotas, and constraints.
Azure Firewall doesn't move or store customer data outside the region where it's deployed.
No, Azure Firewall in secured virtual hubs (vWAN) isn't currently supported in Qatar.
Yes, Azure Firewall supports both inbound and outbound traffic filtering. Inbound filtering is typically used for non-HTTP protocols such as RDP, SSH, and FTP. For inbound HTTP and HTTPS traffic, consider using a web application firewall like Azure Web Application Firewall (WAF) or the TLS offload and deep packet inspection features of Azure Firewall Premium.
Yes, Azure Firewall Basic supports forced tunneling.
Why does a TCP ping or similar tool appear to connect to a target FQDN even when no rule allows the traffic?
A TCP ping doesn't actually connect to the target FQDN. Azure Firewall blocks connections to any target IP address or FQDN unless explicitly allowed by a rule.
In the case of a TCP ping, if no rule allows the traffic, the Firewall itself responds to the client's TCP ping request. This response doesn't reach the target IP address or FQDN and isn't logged. If a network rule explicitly allows access to the target IP address or FQDN, the ping request reaches the target server, and its response is relayed back to the client. This event is logged in the Network rules log.
No, Azure Firewall doesn't natively support BGP peering. However, the Autolearn SNAT routes feature indirectly uses BGP through Azure Route Server.
You can use Azure PowerShell to deallocate and allocate the Azure Firewall. The process varies depending on the configuration.
For a firewall without a Management NIC:
# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw
# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw
For a firewall with a Management NIC:
# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw
# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw
For a firewall in a secured virtual hub:
# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw
# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw
Note
When stopping and starting the firewall, billing stops and starts accordingly. However, the private IP address might change, which can affect connectivity if route tables are configured.
It's recommended to configure availability zones during initial deployment. However, you can reconfigure them after deployment if:
- The firewall is deployed in a virtual network (not supported in secured virtual hubs).
- The region supports availability zones.
- All attached public IP addresses are configured with the same zones.
To reconfigure availability zones:
- Deallocate the firewall:
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name" $azfw.Deallocate() Set-AzFirewall -AzureFirewall $azfw - Update the zone configuration and allocate the firewall:
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name" $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name" $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip" $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip" $azfw.Allocate($vnet, $pip, $mgmtPip) $azfw.Zones = 1, 2, 3 Set-AzFirewall -AzureFirewall $azfw
Yes:
- The Azure Firewall and virtual network must be in the same resource group.
- The public IP address can be in a different resource group.
- All resources (Azure firewall, virtual network, public IP) must be in the same subscription.
A Failed provisioning state indicates that a configuration update failed on one or more backend instances. The Azure Firewall remains operational, but the configuration might be inconsistent. Retry the update until the provisioning state changes to Succeeded.
Azure Firewall uses an active-active configuration with multiple backend nodes. During planned maintenance, connection draining ensures graceful updates. For unplanned failures, a new node replaces the failed one, and connectivity is typically restored within 10 seconds.
Yes, firewall names are limited to 50 characters.
A /26 subnet ensures sufficient IP addresses for scaling as the Azure Firewall provisions extra virtual machine instances.
No, a /26 subnet is sufficient for all scaling scenarios.
Azure Firewall scales automatically based on CPU usage, throughput, and connection count. Throughput capacity ranges from 2.5–3 Gbps initially to 30 Gbps (Standard SKU) or 100 Gbps (Premium SKU).
Yes. For details, see Azure subscription and service limits, quotas, and constraints.
No, moving an IP Group to another resource group isn't currently supported.
A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if there's no activity. Azure Firewall TCP Idle Timeout is four minutes. This setting isn't user configurable, but you can contact Azure Support to increase the Idle Timeout for inbound and outbound connections up to 15 minutes. Idle Timeout for east-west traffic can't be changed.
If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained. A common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. For more information, see the .NET examples.
Yes, but you must configure the firewall in Forced Tunneling Mode. This configuration creates a management interface with a public IP address that is used by Azure Firewall for its operations. This public IP address is for management traffic. It's used exclusively by the Azure platform and can't be used for any other purpose. The tenant data path network can be configured without a public IP address, and Internet traffic can be forced tunneled to another Firewall or completely blocked.
Yes. For more information, see Backup Azure Firewall and Azure Firewall Policy with Logic Apps.
For secure access to PaaS services, we recommend service endpoints. You can choose to enable service endpoints in the Azure Firewall subnet and disable them on the connected spoke virtual networks. This way you benefit from both features: service endpoint security and central logging for all traffic.
Can Azure Firewall in a hub virtual network forward and filter network traffic between multiple spoke virtual networks?
Yes, you can use Azure Firewall in a hub virtual network to route and filter traffic between multiple spoke virtual network. Subnets in each of the spoke virtual networks must have a UDR pointing to the Azure Firewall as a default gateway for this scenario to work properly.
Can Azure Firewall forward and filter network traffic between subnets in the same virtual network or peered virtual networks?
Yes. However, configuring the UDRs to redirect traffic between subnets in the same virtual network requires more attention. While using the virtual network address range as a target prefix for the UDR is sufficient, this also routes all traffic from one machine to another machine in the same subnet through the Azure Firewall instance. To avoid this, include a route for the subnet in the UDR with a next hop type of virtual network. Managing these routes might be cumbersome and prone to error. The recommended method for internal network segmentation is to use Network Security Groups, which don't require UDRs.
Azure Firewall doesn't SNAT when the destination IP address is a private IP range per IANA RFC 1918 or IANA RFC 6598 for private networks. If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one of the firewall private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to not SNAT your public IP address range. For more information, see Azure Firewall SNAT private IP address ranges.
In addition, traffic processed by application rules are always SNAT-ed. If you want to see the original source IP address in your logs for FQDN traffic, you can use network rules with the destination FQDN.
Forced tunneling is supported when you create a new firewall. You can't configure an existing firewall for forced tunneling. For more information, see Azure Firewall forced tunneling.
Azure Firewall must have direct Internet connectivity. If your AzureFirewallSubnet learns a default route to your on-premises network via BGP, you must override this with a 0.0.0.0/0 UDR with the NextHopType value set as Internet to maintain direct Internet connectivity.
If your configuration requires forced tunneling to an on-premises network and you can determine the target IP prefixes for your Internet destinations, you can configure these ranges with the on-premises network as the next hop via a user defined route on the AzureFirewallSubnet. Or, you can use BGP to define these routes.
- URL - Asterisks work when placed on the right-most or left-most side. If it is on the left, it can't be part of the FQDN.
- FQDN - Asterisks work when placed on the left-most side.
- GENERAL - Asterisks on the left-most side mean literally anything to the left matches, meaning multiple subdomains and/or potentially unwanted domain name variations are matched - see the following examples.
Examples:
| Type | Rule | Supported? | Positive examples |
|---|---|---|---|
| TargetURL | www.contoso.com |
Yes | www.contoso.comwww.contoso.com/ |
| TargetURL | *.contoso.com |
Yes | any.contoso.com/sub1.any.contoso.com |
| TargetURL | *contoso.com |
Yes | example.anycontoso.comsub1.example.contoso.comcontoso.comWarning: this usage of wildcard also allows potentially undesired/risky variations such as th3re4lcontoso.com - use with caution. |
| TargetURL | www.contoso.com/test |
Yes | www.contoso.com/testwww.contoso.com/test/www.contoso.com/test?with_query=1 |
| TargetURL | www.contoso.com/test/* |
Yes | www.contoso.com/test/anythingNote: www.contoso.com/test doesn't match (last slash) |
| TargetURL | www.contoso.*/test/* |
No | |
| TargetURL | www.contoso.com/test?example=1 |
No | |
| TargetURL | www.contoso.* |
No | |
| TargetURL | www.*contoso.com |
No | |
| TargetURL | www.contoso.com:8080 |
No | |
| TargetURL | *.contoso.* |
No | |
| TargetFQDN | www.contoso.com |
Yes | www.contoso.com |
| TargetFQDN | *.contoso.com |
Yes | any.contoso.comNote: If you want to specifically allow contoso.com, you must include contoso.com in the rule. Otherwise, the connection is dropped by default because the request doesn't match any rule. |
| TargetFQDN | *contoso.com |
Yes | example.anycontoso.comcontoso.com |
| TargetFQDN | www.contoso.* |
No | |
| TargetFQDN | *.contoso.* |
No |
No. Azure Firewall blocks Active Directory access by default. To allow access, configure the AzureActiveDirectory service tag. For more information, see Azure Firewall service tags.
Yes, you can use Azure PowerShell to do it:
# Add a Threat Intelligence allowlist to an Existing Azure Firewall.
# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
-FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)
# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)
Set-AzFirewall -AzureFirewall $fw
Azure Firewall currently uses TCP/UDP source ports for outbound SNAT traffic, with no idle wait time. When a TCP/UDP connection is closed, the TCP port used is immediately seen as available for upcoming connections.
As a workaround for certain architectures, you can deploy and scale with NAT Gateway with Azure Firewall to provide a wider pool of SNAT ports for variability and availability.
Specific NAT behaviors depend on the firewall's configuration and the type of NAT that's configured. For example, the firewall has DNAT rules for inbound traffic, and network rules and application rules for outbound traffic through the firewall.
For more information, see Azure Firewall NAT Behaviors.
For any planned maintenance, connection draining logic gracefully updates backend nodes. Azure Firewall waits 90 seconds for existing connections to close. In the first 45 seconds, the backend node doesn't accept new connections, and in the remaining time it responds with RST to all incoming packets. If needed, clients can automatically re-establish connectivity to another backend node.
How does Azure Firewall handle VM instance shutdowns during Virtual Machine Scale Set scale in (scale down) or fleet software upgrades?
An Azure Firewall VM instance shutdown might occur during Virtual Machine Scale Set scale in (scale down) or during fleet software upgrade. In these cases, new incoming connections are load balanced to the remaining firewall instances and aren't forwarded to the down firewall instance. After 45 seconds, the firewall starts rejecting existing connections by sending TCP RST packets. After another 45 seconds the firewall VM shuts down. For more information, see Load Balancer TCP Reset and Idle Timeout.
Azure Firewall gradually scales when average throughput or CPU consumption is at 60%, or the number of connections usage is at 80%. For example, it starts to scale out when it reaches 60% of its maximum throughput. Maximum throughput numbers vary based on the Azure Firewall SKU and enabled features. For more information, see Azure Firewall performance.
Scale out takes five to seven minutes. When performance testing, make sure you test for at least 10 to 15 minutes, and start new connections to take advantage of newly created Azure Firewall nodes.
When a connection has an Idle Timeout (four minutes of no activity), Azure Firewall gracefully terminates the connection by sending a TCP RST packet.