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.

 

8 thoughts on “Trying out the Azure Firewall in a Hub & Spoke deployment model

  1. I can’t seem to find an example of how incoming traffic is handled, I mean, if host multiple sites on the different spoke vnet’s, how do you forward incoming traffic to the correct spoke? Or am I totally not understanding how this all works?

      1. I don’t think so, or I wouldn’t know how to. You can only use ip adresses in destination, no fqdn. It doesn’t work with port 80 (or 22). So I have no idea how I can put a firewall in front of my web applications on different VNETs.

      2. The most typical use case for the Azure firewall is mostly the concept of the “Southbound” firewall (meaning, inter vnet traffic and/or outgoing traffic). Whilst it should be able to do incomming traffic via DNAT, my personal advice would be to put a WAF (Azure Application Gateway) as the “Northbound” firewall (incomming traffic). Does that make sense?

  2. Thank you for the suggestion. At the moment I already have several AKS clusters (dev, test etc), and on each cluster I already managed to install an Application Gateway with WAF enabled. I also want to do ip filtering on the inbound connections, and I was under the impression that the Application Gateway subnet doesn’t let you create an NSG but I mistakenly put the Gateway into a Gateway Subnet, while it can also live inside a normal subnet with an NSG (I just found that out while typing this ;)). But still, I would think it should be possible to have a more advanced firewall in front of the WAF’s. Perhaps this is possible with a Barracude appliance but that is (obviously) not my expertise.

      1. The IP filtering is for external traffic, internal traffic filtering is handled by k8s network policies. Thanks for the tip about the Front Door, I’ll have to look into it how it relates to WAF and Firewall.

        PS: ik lees net via je sidebar twitter dat je ook een Vlaming bent haha, toch niet Antwerpen? Dan trakteer je ik een pintje voor je hulp πŸ˜‰

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.