Azure Firewall Manager is now generally available and includes Azure Firewall Policy, Azure Firewall in a Virtual WAN Hub (Secure Virtual Hub), and Hub Virtual Network. In addition, we are introducing several new capabilities to Firewall Manager and Firewall Policy to align with the standalone Azure Firewall configuration capabilities.

Key features in this release include:

  • Threat intelligence-based filtering allow list in Firewall Policy is now generally available.
  • Multiple public IP addresses support for Azure Firewall in Secure Virtual Hub is now generally available.
  • Forced tunneling support for Hub Virtual Network is now generally available.
  • Configuring secure virtual hubs with Azure Firewall for east-west traffic (private) and a third-party security as a service (SECaaS) partner of your choice for north-south traffic (internet bound).
  • Integration of third-party SECaaS partners are now generally available in all Azure public cloud regions.
  • Zscaler integration will be generally available on July 3, 2020. Check Point is a supported SECaaS partner and will be in preview on July 3, 2020. iboss integration will be generally available on July 31, 2020.
  • Support for domain name system (DNS) proxy, custom DNS, and fully-qualified domain name (FQDN) filtering in network rules using Firewall Policy are now in preview.

    Azure Firewall Manager partners Zscaler, Check Point, and iboss.

    Firewall Policy is now generally available

    Firewall Policy is an Azure resource that contains network address translation (NAT), network, and application rule collections, as well as threat intelligence and DNS settings. It’s a global resource that can be used across multiple Azure Firewall instances in Secured Virtual Hubs and Hub Virtual Networks. Firewall policies work across regions and subscriptions.

    You do not need Firewall Manager to create a firewall policy. There are many ways to create and manage a firewall policy, including using REST API, PowerShell, or command-line interface (CLI).

    After you create a firewall policy, you can associate the policy to one or more firewalls using Firewall Manager or using REST API, PowerShell, or CLI.  Refer to the policy-overview document for a more detailed comparison of rules and policy.

    Migrating standalone firewall rules to Firewall Policy

    You can also create a firewall policy by migrating rules from an existing Azure Firewall. You can use a script to migrate firewall rules to Firewall Policy, or you can use Firewall Manager in the Azure portal.

    Example of importing rules from an existing Azure Firewall.

    Importing rules from an existing Azure Firewall.

    Firewall Policy pricing

    If you just create a Firewall Policy resource, it does not incur any charges. Additionally, a firewall policy is not billed if it is associated with just a single Azure firewall. There are no restrictions on the number of policies you can create.

    Firewall Policy pricing is fixed per Firewall Policy per region. Within a region, the price for Firewall Policy managing five firewalls or 50 firewalls is the same. The following example uses four firewall policies to manage 10 distinct Azure firewalls:

    • Policy 1: cac2020region1policy—Associated with six firewalls across four regions. Billing is done per region, not per firewall.
    • Policy 2: cac2020region2policy—Associated with three firewalls across three regions and is billed for three regions regardless of the number of firewalls per region.
    • Policy 3: cac2020region3policy—Not billed because the policy is not associated with more than one firewall.
    • Policy 4: cacbasepolicy—A central policy that is inherited by all three policies. This policy is billed for five regions. Once again, the pricing is lower compared to per-firewall billing approach.

    Example of Firewall Policy billing.

    Firewall Policy billing example.

    Configure a threat intelligence allow list, DNS proxy, and custom DNS

    With this update, Firewall Policy supports additional configurations including custom DNS and DNS proxy settings (preview) and a threat intelligence allow list. SNAT Private IP address range configuration is not yet supported but is in our roadmap.

    While Firewall Policy can typically be shared across multiple firewalls, NAT rules are firewall specific and cannot be shared. You can still create a parent policy without NAT rules to be shared across multiple firewalls and a local derived policy on specific firewalls to add the required NAT rules. Learn more about Firewall Policy.

    Firewall Policy now supports IP Groups

    IP Groups is a new top-level Azure resource in that allows you to group and manage IP addresses in Azure Firewall rules. Support for IP Groups is covered in more detail in our recent Azure Firewall blog.

    Configure secured virtual hubs with Azure Firewall and a third-party SECaaS partner

    You can now configure virtual hubs with Azure Firewall for private traffic (virtual network to virtual network/branch to virtual network) filtering and a security partner of your choice for internet (virtual network to internet/branch to internet) traffic filtering.

    A security partner provider in Firewall Manager allows you to use your familiar, best-in-breed, third-party SECaaS offering to protect internet access for your users. With a quick configuration, you can secure a hub with a supported security partner, and route and filter internet traffic from your virtual networks (VNets) or branch locations within a region. This is done using automated route management, without setting up and managing User Defined Routes (UDRs).

    You can create a secure virtual hub using Firewall Manager’s Create new secured virtual hub workflow. The following screenshot shows a new secure virtual hub configured with two security providers.

    New secure virtual hub configured with two security providers.

    Creating a new secure virtual hub configured two security providers.

    Securing connectivity

    After you create a secure hub, you need to update the hub security configuration and explicitly configure how you want internet and private traffic in the hub to be routed. For private traffic, you don’t need to specify prefixes if it’s in the RFC1918 range. If your organization uses public IP addresses in virtual networks and branches, you need to add those IP prefixes explicitly.

    To simplify this experience, you can now specify aggregate prefixes instead of specifying individual subnets. Additionally, for internet security via a third-party security provider, you need to complete your configuration using the partner portal. Please see the security partner provider page for more details.

    Example of how to select a third-party SECaaS for internet traffic filtering.

    Selecting a third-party SECaaS for internet traffic filtering.

    Secured virtual hub pricing

    A secured virtual hub is an Azure Virtual WAN Hub with associated security and routing policies configured by Firewall Manager. Pricing for secured virtual hubs depends on the security providers configured.

    Pricing options for secure virtual hub.

    See the Firewall Manager pricing page for additional details.

    Next steps

    For more information on these announcements, see the following resources: