Azure Firewall: The Limits and a Practical Approach for Large Environments

Azure Firewall: The Limits and a Practical Approach for Large Environments

If you, like me, work with Azure, you know that the Azure Firewall is an essential component of your network security. It’s a powerful service, but like any tool, it has its limitations—particularly in large, complex environments. In this blog, I’ll share my experiences with the limitations of Azure Firewall, specifically the rule collection group limit, the absence of an “internet” tag, and the IP group limit. I’ll also show you how I’ve addressed these challenges.

Introduction to Azure Firewall and Azure Virtual WAN

Before diving into the specific limits and challenges of Azure Firewall, it’s important to establish a basic understanding of what these services entail and how they fit into the broader Azure ecosystem.

Azure Firewall is a cloud-based, managed network security service that protects your Azure resources. It acts as an intelligent firewall, monitoring and filtering both inbound and outbound network traffic based on a set of rules that you configure. These can range from simple rules based on IP addresses and ports to more advanced rules based on FQDNs (Fully Qualified Domain Names) and application protocols. Azure Firewall is not only a crucial security tool but also an essential component of a well-designed network infrastructure in Azure.

Azure Virtual WAN (Wide Area Network) is a networking service that helps you centralize and manage connectivity for large, distributed environments. It provides a global network of hubs where you can bring together various connections. These connections can include: connections to your on-premises locations via VPN or ExpressRoute, connections between virtual networks (VNets) in Azure, or connections to the public internet. A Virtual WAN acts as a central point of management for your network infrastructure and can significantly reduce the complexity of setting up and managing connectivity over long distances. The Azure Firewall can be integrated into a Virtual WAN to improve the security of your entire network. You can choose to place the Azure Firewall in each Virtual HUB, or to use a Secured Virtual HUB where you force all traffic through the firewall.

In the context of this blog post, we’ll discuss the limits and challenges you encounter when configuring Azure Firewall, especially when using it in complex environments with many workloads or in combination with a Virtual WAN infrastructure. We will be focusing specifically on the limitations of rule collection groups, the absence of an “internet” tag, the constraints of IP groups, and how the firewall processes rules.

The Hierarchy: Policies, Rule Collection Groups, Rule Collections, and Rules

The Azure Firewall is built upon a structure that includes policies, rule collection groups, rule collections, and individual rules.

1. Policies: At the highest level, you have policies. A policy contains all settings for a specific firewall. You can associate multiple firewall instances with the same policy, which helps maintain uniformity in your network security configuration.

2. Rule Collection Groups: Within a policy, rules are organized into rule collection groups. These groups help you logically categorize rules, for example by DTAP (Development, Test, Acceptance and Production) environment (as in my approach) or by rule type (DNAT (Destination Network Address Translation), Network, Application). The rule collection groups are processed based on their priority (a lower number is a higher priority), and within each group, the rules are processed in order. It’s crucial to carefully consider the sequence in which you place each rule collection group. The number of rule collection groups is limited, which is where many administrators run into issues.

3. Rule Collections: Within each rule collection group, you have rule collections. A rule collection contains a set of rules of the same type (for example, network rules or application rules). This approach introduces an additional layer of structure for managing your rules within the group.

4. Rules: These are the individual firewall rules themselves. A rule determines how the firewall handles a specific type of traffic based on source and destination addresses, ports, and protocols. You can have rules that allow or deny traffic.

Rule Collection Group Limit: The Challenge

Azure Firewall Policies use rule collection groups to organize your firewall rules. This helps keep your rules structured and maintain an overview. However, the number of rule collection groups per firewall policy is limited. For policies created after July 2022, the limit is 90, while for older policies, the limit is 50, as described by Microsoft in this article.

My Approach: Rule Collections per DTAP Environment

In the past, I used one rule collection group per workload, but that proved to be an unscalable solution. During an assessment for a client, I realized this method wouldn’t work because the client had more than 90 workloads and a DTAP (Development, Test, Acceptance, Production) environment. I needed a different approach. My new strategy is to create 5 rule collection groups per DTAP environment.

• Why this approach? By creating 5 rule collection groups for each DTAP environment, I can work around the limit and still manage rules per environment in a clear and organized manner.
• How it works:
  • DNAT (Inbound): A rule collection group for all incoming DNAT rules.
  • Network Inbound: A rule collection group for all incoming network rules.
  • Network Outbound: A rule collection group for all outgoing network rules.
  • Application Inbound: A rule collection group for all incoming application rules.
  • Application Outbound: A rule collection group for all outgoing application rules.
• Priority: Managing the priority of the rule collection groups is crucial. Rules with a lower priority (e.g., 100) are processed before those with a higher priority (e.g., 65000). Start with lower priority numbers and work your way up, leaving room (e.g., 100, 200, 300, etc.) for future additions. I’ve created priority ranges for each DTAP environment. For D, I use 10000 to 22499; for T, 22500 to 34999; for A, 35000 to 47499; and for P, 47000 to 65000.
• IP Ranges: Assign dedicated IP ranges for the D, T, A, and P environments that have enough space to accommodate the required resources.
• Deny en Allow: Use “allow” for rules that explicitly permit traffic and “deny” for rules that explicitly block traffic.

Below is an example of production rules: 

The Rule Collection then contains the rules for a specific workload.

Rule Collection Naming

For the name of a rule collection I use the following template:
<Workload-name>-<Direction>-<Action>

This makes it easier to find a rule in the Portal if you have to troubleshoot something.

Automation

Adopting an Infrastructure-as-Code (IaC) strategy is crucial for maintaining consistency in Azure Firewall configurations. By using a PowerShell script, for example, you can systematically enforce naming conventions and rule priorities, reducing the likelihood of mistakes and oversights. Splitting your configuration into multiple Rule Collection Groups is especially useful—each group can be treated as its own resource, making it easy to deploy updates incrementally. You can first apply changes in Development, Test, and Acceptance, and only move them into Production once they’ve been validated.

This automated approach also incorporates important safeguards. For instance, if an invalid destination range is entered (e.g., 192.168.1.1/24 instead of the correct 192.168.1.0/24), the script flags the error and prevents deployment of an incorrect policy. It similarly checks for duplicate Rule Collection names, which must be unique. Although it doesn’t yet correct errors automatically, it provides essential feedback to keep your firewall policy accurate and secure. The PowerShell script will output any detected errors to the console, guiding you toward the exact issue so you can quickly resolve it.

The script also sets the network outbound rules to the correct priority.

The Absence of an “Internet” Tag and Its Implications

A key limitation is the absence of an “Internet” service tag as my colleague Gert Jan Huisman pointed out to me. In other Azure services, such as NSGs and User Defined Routes (UDRs), this tag is available, making it easy to configure internet traffic. Azure Firewall doesn’t have this tag. This means you need to use the full IP range 0.0.0.0/0 to define the internet. This has implications for how you set up your rules. If you create a rule to allow a server to access the internet using ‘any’ (i.e., *), your internal network is also included. This is something you definitely want to avoid.

• Why is this difficult? It makes configuration more complex and increases the risk of unintentionally granting access to internal servers where it’s not intended.
• My Approach: I use * as the destination address in rules that handle internet traffic. To ensure proper control, I create a Network-Outbound-Deny Rule at a low priority (i.e., a high number) for internal network ranges. Then I add the rules that grant internet access. This ensures that all outbound traffic that should only reach the internet does not have access to the internal network. The image below shows an example of this configuration.

Details of the first rule in the image above:

Here, the internal production network range(s) are listed under “Source” and the RFC-1918 ranges under “Destination”.

Details of the second rule in the image above (example rule):

Here, you can add one or more servers under “Source,” and “*” as the “Destination,” allowing them to reach servers on the internet.

With this approach, you prevent internal servers from inadvertently accessing other internal servers where such access isn’t explicitly needed.

IP Groups Limit

Due to the limitation of 200 IP groups and 5,000 addresses per group, I’ve decided not to use IP groups anymore. The limit on the number of IP groups is relatively low, which I see as a constraint rather than an enhancement. Since all configurations are already stored in code, the necessity to use IP groups has also decreased.

How Azure Firewall Processes Rules

It’s crucial to understand how Azure Firewall processes its rules. The firewall uses a strict order:

1. DNAT Rules:
2. Network Rules:
3. Application Rules:

• DNAT Rules: Used to translate incoming traffic from the internet to private IP addresses within your virtual network. I recommend to not use these rules for any HTTP/HTTPS incoming connections unless there is no real alternative. I would use for example Azure Front Door or an Azure Application Gateway for incoming HTTP/HTTPS connections.
• Network Rules: Define rules based on protocols (TCP/UDP), source and destination IP addresses, and ports.
• Application Rules: Configure rules based on Fully Qualified Domain Names (FQDNs) and/or HTTP/HTTPS protocols. This is handy for allowing or blocking access to specific websites.

Why is this order important? If a rule matches at an earlier stage (e.g., DNAT), later stages (e.g., network and application) won’t be evaluated. This is important to consider when designing your rules.

Conclusion

Working with Azure Firewall in large environments can be complex. It’s essential to understand its limitations and adjust your approach accordingly. By using a structured method—such as the five rule collection groups per DTAP environment I outlined here, the Block Outbound Rule to control internet traffic, and avoiding IP groups—you can circumvent limitations and manage a secure, efficient infrastructure. Keep experimenting, learning, and consulting the community to stay current with the latest best practices.

I hope this blog post helps you with your Azure Firewall configurations. I a next blog I will discuss the configurations, scripts and pipeline steps that I use to automate it all.