Last Update: Sep 04, 2024 | Published: Feb 04, 2019
Because of the cost of Azure Firewall, I would normally expect it to be used in larger implementations. But high-value assets do not have to be large; a few virtual machines can be responsible for millions of dollars of business – I have seen it – and that is something that the business will wish to protect.
Therefore, one might expect to see a design such as the below. Although Microsoft normally sees Azure Firewall being deployed into a hub-and-spoke virtual network deployment (peered VNets), you can deploy Azure Firewall into a dedicated subnet in a single VNet.
For the purposes of illustration and explanation, I have kept this architecture simple, but I will expand on it later in the post.
As is required by Azure Firewall, a dedicated subnet is deployed. This subnet, which must be called AzureFirewallSubnet, must have a subnet mask of at least /25.
The Azure Firewall has two IP addresses:
A subnet for web servers is created. This subnet has:
Let’s dig into routing for a moment. If your intention is to route all traffic, including internal traffic, through the firewall then you must create very granular rules. 0.0.0.0/0 will route external traffic through the firewall; traffic to the same/other subnets in the same VNet will route directly, bypassing the firewall. To get the web servers to route to the backend (let’s assume the backend is 10.0.3.0/24) then you must create a rule sending all traffic to 10.0.3.0/24 to the internal IP address of the firewall, as well as a rule for 0.0.0.0/0.
Taking full control over routing and sending all internal traffic through the firewall can be complicated, especially if there will be other services with public IP addresses (split routing). But the benefits of this “micro-segmentation” are:
You might notice that the web servers have an internal IP load balancer; this provides a single internal IP address (translation address) that can be used for NAT rules.
A subnet for backend servers is created. This subnet has:
The conversation about routing from above can be repeated here. Note that no traffic will NAT from the Internet to this subnet. Instead, application and/or network rules in the Azure Firewall will allow traffic to flow from the web subnet to the backend subnet – assuming you followed the above advice on taking full control over routing.
Let’s say you have other services that will have public IP addresses. Maybe a jump box virtual machine (bastion host) will have a dedicated PIP, or maybe you want to put a web application gateway/firewall in front of the web servers (another dedicated PIP)? If you anything like these, then you must be careful about routing. If you have a route table that sends all traffic through the firewall, then:
In this case, you will have to pay much more attention to subnet design, machine/appliance placement, and how traffic routes to the outside world.