Optimizing Azure Firewall: Avoiding Unintended VNET-to-VNET Traffic

We want to share an important best pracice with anyone that manages or implements Azure firewalls. Special thanks to the findings and valuable input from my colleague Gert Jan Huisman.

🤔 The Problem:

Azure Firewall rules are processed based on priority (from 0 to 64999). As of writing, there is no specific alias for designating public internet traffic. This can inadvertently allow traffic between VNETs.

🚨 Risk:

The risk arises when someone tries to route traffic from a VNET to the internet and uses "*" (any) in the destination field. While this allows traffic to the internet, it also permits traffic to other networks (VNETs) within Azure. This can pose a significant security risk if not intended and not mitigated by another rule.

🛠️ Proposed Solution:

Create a Rule Collection Group named 'Internet-Access' with priority 64900 and add the following Rule Collections:

• Deny-Private-Ranges: Create this Rule Collection with priority 64901. Add a single network rule that blocks traffic to and from private IP addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
• Allow-Outbound: Create this Rule Collection with priority 64902. Add as many rules as needed to allow your traffic specific internet access. By placing this Rule Collection right after the Deny-Private-Ranges, you ensure that the firewall first blocks all traffic between private IP addresses, preventing you from accidentally allowing traffic to a private IP address.

By following this structure, you can add an extra layer of security and prevent unintended VNET to VNET traffic. If you do need VNET to VNET traffic, create a specific rule with a higher priority (e.g., 1001).

Have questions or want to know more? Feel free to send me a message or leave a comment.