Trying out the Azure Firewall in a Hub & Spoke deployment model

Introduction

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.

 

Architecture

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!

Diving in!

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” ;

If correct, then fire away your test, and … BADABOOM! 😉  

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!

 

Closing Thoughts

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.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.