Two new key features in Azure Firewall—forced tunneling and SQL FQDN filtering—are now generally available. Additionally, we increased the limit for multiple public IP addresses from 100 to 250 for both Destination Network Address Translation (DNAT) and Source Network Address Translation (SNAT).
Azure Firewall is a cloud native Firewall as a Service (FWaaS) offering that allows you to centrally govern and log all your traffic flows using a DevOps approach. The service supports both application and network level filtering rules and is integrated with the Microsoft Threat Intelligence feed for filtering known malicious IP addresses and domains. Azure Firewall is highly available with built-in auto scaling.
Forced tunneling support now generally available
Forced tunneling lets you redirect all internet bound traffic from Azure Firewall to your on-premises firewall or to chain it to a nearby network virtual appliance (NVA) for additional inspection. You enable a firewall for forced tunneling when you create a new firewall. As of today, it is not possible to migrate an existing firewall deployment to a forced tunneling mode.
To support forced tunneling, service management traffic is separated from customer traffic. An additional dedicated subnet named AzureFirewallManagementSubnet is required with its own associated public IP address. The only route allowed on this subnet is a default route to the internet, and Border Gateway Protocol (BGP) route propagation must be disabled.
Within this configuration, the AzureFirewallSubnet can now include routes to any on-premises firewall or NVA to process traffic before it’s passed to the internet. You can also publish these routes via BGP to AzureFirewallSubnet if BGP route propagation is enabled on this subnet.
Figure 1. Azure Firewall in forced tunneling mode.
Avoiding SNAT with forced tunneling
Azure Firewall provides automatic SNAT for all outbound traffic to public IP addresses. Azure Firewall doesn’t SNAT when the destination IP address is a private IP address range per IANA RFC 1918. This logic works perfectly when you egress directly to the internet. However, with forced tunneling enabled, internet-bound traffic ends up SNATed to one of the firewall private IP addresses in AzureFirewallSubnet, hiding the source from your on-premises firewall. You can configure Azure Firewall to not SNAT regardless of the destination IP address by adding “0.0.0.0/0” as your private IP address range. Note that with this configuration, Azure Firewall can never egress directly to the internet. For more information, see Azure Firewall SNAT private IP address ranges.
Figure 2. Azure Firewall doesn’t SNAT private IP prefixes configuration.
Routing to public PaaS and Office 365
While Azure Firewall forced tunneling allows you to direct all internet-bound traffic to your on-premises firewall or a nearby NVA, this is not always desirable. For example, it is likely preferable to egress to public Platform as a Service (PaaS) or Office 365 directly. It is possible to achieve this by adding User Defined Routes (UDR) to the AzureFirewallSubnet with next hop type “Internet” for specific destinations. As this definition is more specific than the default route, it will take precedence. See Azure IP Ranges and Service Tags. and Office 365 IP addresses for more information.
As an alternative approach for egressing directly to public PaaS, you can enable Virtual Network (VNet) service endpoints on the AzureFirewallSubnet. These endpoints extend your virtual network private address space and identity to the Azure PaaS services over a direct connection. When enabled, specific routes to the corresponding PaaS services are automatically created. Service endpoints allow you to secure your critical Azure service resources to your VNet only. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network.
It is important to note that with this configuration, you will not be able to add “0.0.0.0/0” as your private IP prefix as shown previously, but you can still add custom ranges that will not be SNATed.
Finally, it is also possible to use Azure Private Endpoint to connect privately and securely to public PaaS services powered by Azure Private Link. However, these connections will bypass your default route to Azure Firewall as described in this documentation. If you require all traffic to go via your firewall, you can mitigate by adding a UDR on all client subnets with the Private Endpoint IP address and a /32 suffix as the destination and Azure Firewall as the next hop. Note that for this configuration to work and for the returned traffic from your private endpoint to go via your firewall as well, you will have to always SNAT, by using 255.255.255.255/32 as your private IP address range.
Figure 3. A UDR to a Storage Private Endpoint pointing to the firewall as a next hop.
SQL FQDN filtering now generally available
You can now configure SQL FQDNs in Azure Firewall application rules. This allows you to limit access from your VNet to only the specified SQL Server instances. You can filter traffic from VNets to an Azure SQL Database, Azure SQL Data Warehouse, Azure SQL Managed Instance, or SQL IaaS instances deployed in your VNets.
SQL FQDN filtering is currently supported in proxy-mode only (port 1433). If you use non-default ports for SQL Infrastructure as a Service (IaaS) traffic, you can configure those ports in the firewall application rules.
If you use SQL in the default redirect mode, you can still filter access using the SQL service tag as part of network rules. Adding redirect mode support to application rules is on our roadmap.
Figure 4. SQL FQDN filtering in Azure Firewall application rules.
Multiple public IP addresses limit increase
You can now use up to 250 public IP addresses with your Azure Firewall for both DNAT and SNAT.
- DNAT—You can translate multiple standard port instances to your backend servers. For example, if you have two public IP addresses, you can translate TCP port 3389 (RDP) for both IP addresses.
- SNAT—Additional ports are available for outbound SNAT connections, reducing the potential for SNAT port exhaustion. Currently, Azure Firewall randomly selects the source public IP address to use for a connection. If you have any downstream filtering on your network, you need to allow all public IP addresses associated with your firewall. Consider using a public IP address prefix to simplify this configuration.
For more information see Deploy an Azure Firewall with multiple public IP addresses.
Next steps
For more information on everything we covered here, see the following: