A few weeks ago the Azure Firewall went into public preview. Today’s post will be around taking it for a spin in a hub & spoke deployment.
First off, what will the architecture of our deployment look like?
- A central hub, where we’ll deploy the Azure Firewall. This will consist of the address space 172.16.0.0/12.
- Two spokes, each with their own address space (10.[1/2].0.0/16) where a UDR will send all traffic to the Azure Firewall (172.16.254.4).
- In each VNET, we’ll deploy a “SUBNET000” in which we’ll setup a vm to do our basic connectivity testing.
- Each spoke is connected with a bidirectional VNET peering with the spokes. Both spokes can only talk to each other over the HUB.
- The Azure firewall will be configured to allow traffic within the 10.0.0.0/8 range.
Warning : Public Preview
First a heads-up notice, this service is currently a preview service. So you have to enable the preview for your subscription!
In regards to the network, I’m assuming that you have your underlying hub & spoke vnet layout already configured (as described above). Do ensure that you have “Allow Forwarded Traffic” enabled on all peering connections!
So let’s get’s started! Go to the marketplace and look for “firewall”
And create one…
And deploy the Azure Firewall to your hub vnet.
Be aware that you cannot choose the subnet you deploy the firewall into. The service expects a subnet called “AzureFirewallSubnet”. If it’s not present, then you’ll get the following error message ;
After a few minutes you’ll have a newly firewall object inside of your resource group.
Where it got private IP from the AzureFirewallSubnet.
And you’ll be able to configure rules ;
Let’s do that ;
- You can choose to create a more granular setup
- Or go for the more broad approach
- Though be aware that * are allowed as input, but the firewall seems to ignore them (probably a bug)
- And it seems 0.0.0.0/0 is currently not a supported format
Once this has been done, create/update your route tables. In this case, I’ll be sending all my non-local/vnet traffic to the firewall ;
Now browse to the NIC of one of the VMs inside of a spoke, and verify the “Effective routes” ;
Update (28/08) upon request ; URL Filtering
A request I got fairly fast was; “Did you test out the URL filtering?” Good question Nills! 😉 I had forgotten about that one. So let’s add an appliation rule…
wait a bit for it…
And let’s see what happened ;
- The first wget fails (error 470)
- Then the rule gets added
- And afterwards the second wget gets through!
The Azure Firewall serves as a viable candidate for hub & spoke models. Though, as you’ve noticed from the screenshots, the capabilities are limited. Where I know it will serve its purpose with a range of customers in its current state, I personally think there is a gap with the typical NextGeneration FireWalls (NGFWs).
Update : Though the URL filtering will be a huge relief to a lot of customers who just wanted to allow things like storage accounts and so on.