Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article helps you understand the current known issues and limitations in Azure Firewall. We update this information as issues are resolved, so check back regularly for the latest status.
Before you deploy Azure Firewall or troubleshoot existing deployments, review these known issues to avoid common problems and plan appropriate workarounds.
For Azure Firewall service limits, see Azure subscription and service limits, quotas, and constraints.
Current capacity constraints
The following zones are currently experiencing capacity constraints:
| Region/Zones | SKU | Restrictions | Recommendation |
|---|---|---|---|
| - Physical zone 2 in North Europe - Physical zone 3 in South East Asia |
Standard and Premium | - You can't deploy a new Azure Firewall to zone 3 in South East Asia or zone 2 in North Europe. - If you stop an existing Azure Firewall that is deployed in these zone, it can't be restarted. For more information, see Physical and logical availability zones. |
We recommend you deploy a new Azure Firewall to the remaining availability zones or use a different region. To configure an existing firewall, see How can I configure availability zones after deployment? |
| US Gov Virginia | Premium | - There's zero capacity for Azure Firewall Premium SKU in US Gov Virginia, both zonal and nonzonal deployments are blocked. | Deploy Azure Firewall Standard SKU or deploy Premium SKU to a different region. |
| Physical zone 3 in US Gov Virginia | Basic and Standard | - Zonal deployments are blocked in physical zone 3 in US Gov Virginia. - You must manually select available zones for successful deployment, creating a suboptimal deployment experience. |
Select zones 1 and 2 for zonal deployments or use a different region. |
Warning
If you stop an existing Azure Firewall deployment in any of these capacity-restricted regions, you might not be able to start it again due to ongoing capacity limitations. Plan accordingly before stopping firewall instances in these regions.
Azure Firewall Standard known issues
Azure Firewall Standard has the following known issues:
| Issue | Description | Mitigation |
|---|---|---|
| DNAT support for private IP addresses limited to Standard and Premium versions | Support for DNAT on Azure Firewall private IP address is available only in the Standard and Premium Firewall versions, not in the Basic version. | None |
| Azure Firewall deallocation and allocation process aren't supported when private IP DNAT rules are configured | The Azure Firewall allocation process fails when private DNAT rules are configured | 1. Deallocate the Azure Firewall 2. Delete all the private IP DNAT rules 3. Allocate the Azure Firewall and wait until the private IP gets populated 4. Reconfigure the private IP DNAT rules with the appropriate private IP address |
| 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're exploring options to support non-TCP/UDP protocols for Internet bound traffic in a future release. |
| When an Azure Firewall is deallocated and then allocated again, it might be assigned a new private IP address | After the deallocation and allocation process of the Azure Firewall, a private IP address is assigned dynamically from the Azure Firewall subnet. When a new private IP address is assigned that's different from the previous one, it causes routing issues. | You need to reconfigure the existing User Defined Routes (UDRs) with the new private IP address. A fix is being investigated to retain the private IP address after the allocation process. |
| Child firewall policies don't inherit DNS settings from parent policies. | When you change DNS settings in a parent firewall policy, child policies linked to it might fail to resolve ___domain names in their rules. | Configure DNS settings directly on each child policy instead of relying on the parent policy. We're working on a fix to allow inheritance of DNS settings. |
| Missing PowerShell and CLI support for ICMP | Azure PowerShell and CLI don't support ICMP as a valid protocol in network rules. | It's still possible to use ICMP as a protocol via the portal and the REST API. We're 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're working to make the port: protocol field optional when FQDN tags are used. |
| Moving a firewall to a different resource group or subscription isn't supported | Moving a firewall to a different resource group or subscription isn't supported. | Supporting this functionality is on our roadmap. 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. |
| Threat intelligence alerts might get masked | Network rules with destination 80/443 for outbound filtering masks threat intelligence alerts when configured to alert only mode. | Create outbound filtering for 80/443 using application rules. Or, change the threat intelligence mode to Alert and Deny. |
| With secured virtual hubs, availability zones can only be configured during deployment. | You can't configure Availability Zones after a firewall with secured virtual hubs is deployed. | By design. |
| SNAT on inbound connections | Inbound DNAT rules always change the source IP address for return traffic. | To keep track of the original client IP for web traffic, configure your clients or proxy servers to include the original IP in XFF headers. Azure Firewall preserves these IP addresses in the XFF header and adds the Firewall IP to the XFF header when processing web traffic rules. |
| SQL FQDN filtering support only in proxy mode (port 1433) | For Azure SQL Database, Azure Synapse Analytics, and Azure SQL Managed Instance: SQL FQDN filtering is supported in proxy-mode only (port 1433). For Azure SQL IaaS: If you're using nonstandard ports, you can specify those ports in the application rules. |
For SQL in redirect mode (the default if connecting from within Azure), you can instead filter access using the SQL service tag as part of Azure Firewall network rules. |
| Outbound SMTP traffic on TCP port 25 is blocked | The Azure platform blocks outbound email messages sent directly to external domains (like outlook.com and gmail.com) on TCP port 25. Blocking outbound SMTP traffic on port 25 is the default platform behavior in Azure. Azure Firewall doesn't introduce any more specific restriction. |
Use authenticated SMTP relay services, which typically connect through TCP port 587, but also supports other ports. For more information, see Troubleshoot outbound SMTP connectivity problems in Azure. Another option is to deploy Azure Firewall in a standard Enterprise Agreement (EA) subscription. Azure Firewall in an EA subscription can communicate with public IP addresses using outbound TCP port 25. It might work in other subscription types, but not guaranteed. For private IP addresses like virtual networks, VPNs, and Azure ExpressRoute, Azure Firewall supports an outbound connection on TCP port 25. |
| SNAT port exhaustion | Azure Firewall currently supports 2,496 ports per Public IP address per backend Virtual Machine Scale Set instance. By default, there are two Virtual Machine Scales Set instances. So, there are 4,992 ports per flow (destination IP, destination port, and protocol (TCP or UDP). The firewall scales up to a maximum of 20 instances. | SNAT port exhaustion is a platform limitation. You can work around the limits by configuring Azure Firewall deployments with a minimum of five public IP addresses for deployments susceptible to SNAT exhaustion. Adding more public IP addresses increases the SNAT ports available by five times. Allocate from an IP address prefix to simplify downstream permissions. For a more permanent solution, you can deploy a NAT gateway to overcome the SNAT port limits. NAT gateway deployment is supported for virtual network deployments. For more information, see Scale SNAT ports with Azure Virtual Network NAT. |
| DNAT isn't supported with Forced Tunneling enabled | Firewalls deployed with Forced Tunneling enabled can't support inbound access from the Internet because of asymmetric routing. | The lack of DNAT support with Forced Tunneling is by design because of asymmetric routing. The return path for inbound connections goes through the on-premises firewall, which doesn't see the connection established. |
| Outbound Passive FTP might not work for Firewalls with multiple public IP addresses, depending on your FTP server configuration. | Passive FTP establishes different connections for control and data channels. When a Firewall with multiple public IP addresses sends data outbound, it randomly selects one of its public IP addresses for the source IP address. FTP might fail when data and control channels use different source IP addresses, depending on your FTP server configuration. | An explicit SNAT configuration is planned. In the meantime, you can configure your FTP server to accept data and control channels from different source IP addresses (see an example for IIS). Alternatively, consider using a single IP address when experiencing FTP connectivity issues. |
| Inbound Passive FTP might not work depending on your FTP server configuration | Passive FTP establishes different connections for control and data channels. Inbound connections on Azure Firewall are SNATed to one of the firewall private IP addresses to ensure symmetric routing. FTP might fail when data and control channels use different source IP addresses, depending on your FTP server configuration. | Preserving the original source IP address is being investigated. In the meantime, you can configure your FTP server to accept data and control channels from different source IP addresses. |
| Active FTP doesn't work when the FTP client must reach an FTP server across the internet. | Active FTP utilizes a PORT command from the FTP client that directs the FTP server what IP and port to use for the data channel. The PORT command utilizes the private IP of the client that can't be changed. Client-side traffic traversing the Azure Firewall is NATed for Internet-based communications, making the PORT command seen as invalid by the FTP server. | Active FTP failure is a general limitation of Active FTP when used with client-side NAT. |
| NetworkRuleHit metric is missing a protocol dimension | The ApplicationRuleHit metric allows filtering based protocol, but this capability is missing in the corresponding NetworkRuleHit metric. | A fix is being investigated. |
| NAT rules with ports between 64000 and 65535 are unsupported | Azure Firewall allows any port in the 1-65535 range in network and application rules, however NAT rules only support ports in the 1-63999 range. | The restriction on NAT rule ports is a current limitation. |
| Configuration updates might take five minutes on average | An Azure Firewall configuration update can take three to five minutes on average, and parallel updates aren't supported. | A fix is being investigated. |
| Azure Firewall uses SNI TLS headers to filter HTTPS and MSSQL traffic | If browser or server software doesn't support the Server Name Indicator (SNI) extension, you can't connect through Azure Firewall. | If browser or server software doesn't support SNI, then you might be able to control the connection using a network rule instead of an application rule. See Server Name Indication for software that supports SNI. |
| Can't add firewall policy tags using the portal or Azure Resource Manager (ARM) templates | Azure Firewall Policy has a patch support limitation that prevents you from adding a tag using the Azure portal or ARM templates. The following error is generated: Couldn't save the tags for the resource. | A fix is being investigated. Or, you can use the Azure PowerShell cmdlet Set-AzFirewallPolicy to update tags. |
| IPv6 not currently supported | If you add an IPv6 address to a rule, the firewall fails. | Use only IPv4 addresses. IPv6 support is under investigation. |
| Removing RuleCollectionGroups using ARM templates not supported. | Removing a RuleCollectionGroup using ARM templates isn't supported and results in failure. | Removing RuleCollectionGroups using ARM templates isn't a supported operation. |
| DNAT rule for allow any (*) will SNAT traffic. | If a DNAT rule allows any (*) as the Source IP address, then an implicit Network rule matches VNet-VNet traffic and will always SNAT the traffic. | The automatic SNAT behavior for DNAT rules with any source is a current limitation. |
| Adding a DNAT rule to a secured virtual hub with a security provider isn't supported. | When you add a DNAT rule to a secured virtual hub with a security provider, it results in an asynchronous route for the returning DNAT traffic, which goes to the security provider. | Not supported. |
| Error encountered when creating more than 2,000 rule collections. | The maximal number of NAT/Application or Network rule collections is 2000 (Resource Manager limit). | The 2,000 rule collection limit is a current limitation. |
| Can’t deploy Firewall with Availability Zones with a newly created Public IP address | When you deploy a Firewall with Availability Zones, you can’t use a newly created Public IP address. | First create a new zone redundant Public IP address, then assign this previously created IP address during the Firewall deployment. |
| Associating a Public IP address with Azure Firewall isn't supported in a cross-tenant scenario. | If you create a Public IP address in tenant A, you can't associate it with a firewall deployed in tenant B. | None. |
| VMs behind Azure Firewall can't connect to DNAT rule destinations using the firewall's public IP | When VMs route traffic through Azure Firewall and attempt to connect to resources configured with DNAT rules by using the firewall's public IP address, the connection fails. The connection failure occurs because Azure Firewall doesn't support hair pinning traffic from internal VMs to the firewall's own public IP address for DNAT rule destinations. | A solution for this limitation is currently in development. |
Azure Firewall Premium known issues
Note
Any issue that applies to Standard also applies to Premium.
Azure Firewall Premium has the following known issues:
| Issue | Description | Mitigation |
|---|---|---|
| ESNI support for FQDN resolution in HTTPS | Encrypted SNI isn't supported in HTTPS handshake. | Today only Firefox supports ESNI through custom configuration. Suggested workaround is to disable the ESNI feature. |
| Client Certification Authentication isn't supported | Client certificates are used to build a mutual identity trust between the client and the server. Client certificates are used during a TLS negotiation. Azure firewall renegotiates a connection with the server and has no access to the private key of the client certificates. | None |
| QUIC/HTTP3 | QUIC is the new major version of HTTP. It's a UDP-based protocol over 80 (PLAN) and 443 (SSL). FQDN/URL/TLS inspection isn't supported. | Configure passing UDP 80/443 as network rules. |
| Untrusted customer signed certificates | The firewall doesn't trust customer signed certificates when it receives them from an intranet-based web server. | A fix is being investigated. |
| IDPS displays wrong source IP address for HTTP alerts without TLS inspection | When IDPS generates alerts for plain text HTTP traffic to public IP addresses, it displays the internal IP address instead of the original source IP address. | A fix is being investigated. |
| Certificate Propagation | After a CA certificate is applied on the firewall, it might take between 5-10 minutes for the certificate to take effect. | A fix is being investigated. |
| TLS 1.3 support | TLS 1.3 is partially supported. The TLS tunnel from client to the firewall is based on TLS 1.2, and from the firewall to the external Web server is based on TLS 1.3. | Updates are being investigated. |
| TLSi intermediate CA certificate expiration | In some unique cases, the intermediate CA certificate can expire two months before the original expiration date. | Renew the intermediate CA certificate two months before the original expiration date. A fix is being investigated. |