How to Create Network Rules in Azure Firewall
Note – you do not need to create network rules when you create NAT rules – the Azure Firewall will automatically create a hidden network rule to match the NAT rule.
The purpose of a network rule is to allow non-HTTP/S traffic between a source and destination. A network rule has 5 properties to define allowed or denied traffic:
- Name: A human-friendly label.
- Protocol: This can be TCP, UDP, ICMP (traceroute or ping) or any.
- Source Addresses: The source of the packet, which can be a wildcard (*) for everything, a specific IP address, or a CIDR block. Note that many sources can be listed, separated by a comma.
- Destination Addresses: The destination of the packet, which can be a wildcard (*) for everything, a specific IP address, or a CIDR block. Note that many destinations can be listed, separated by a comma.
- Destination Ports: What port(s) or services are listening for this traffic at the destination(s). You can specify everything (*) or a port number. Note that you can use a comma to separate multiple entries.
Network Rule Collections
A network rule collection is a set of network rules that are grouped together and share a common priority, a number from 100 to 65000. If you have multiple network rule collections, you can use this priority to order their processing as a packet is inspected. The highest priority (lowest number) is first. Once a packet is matched against a network rule – in other words the packet matches the properties of a network rule in a network rule collection – then processing is stopped. Depending on the network rule collection’s action, the packet is either allowed or denied.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
A useful tip is to stagger rule numbers. For example, you might have rule collections with priorities of 100,200, and 300. If you need to put something between 100 and 200 you create a new rule collection with a priority of 150.
Creating Network Rules
In this set of instructions, I will assume that you have a brand-new Azure Firewall and have no network rule collections and therefore, you have no network rules.
In the Azure Portal, open the Azure Firewall resource and click Rules. Browse to Network Rule Collection and click + Add Network Rule Collection. A pop-up blade called Add Network Rule Collection will appear.
You must configure the network rule collection:
- Name: A human-friendly label to describe the new collection of network rules.
- Priority: Order the processing of network rule collections.
- Action: Allow or deny the traffic that is pattern matched by the rules in this collection.
You then will add one or more network rules, with each rule specifying the pattern to be matched. Any traffic matching this pattern will be allowed or denied based on the Action property of the network rule collection.
One can add or remove rules to an existing network rules collection, and you can use the above process to create more Network Rules Collections.
I have not seen any best practices from Microsoft, but my approach at the moment is to group common functions together into a Network Rule Collection. My above example has 3 network rules to allow management from a central “jump box” virtual machine to other virtual machines that are protected by this Azure Firewall.
As you might figure out from the above screenshot, this is a hub-and-spoke scenario where the Azure Firewall resides alone in a hub virtual network (VNet), and all other services are deployed into spoke VNets. Creating the above rules will allow routing by the Azure Firewall assuming that peering between the VNets and routing on the application subnets has been done correctly.