First thoughts on Azure Firewall

Update…

This article is out of date and no longer accurate, feel free to read it but then please see this post for updates on Azure Firewall one year on…

Microsoft has released the first native Azure Firewall service to public preview.  I’ve taken some time to spin one up and play with it and thought I’d share my initial thoughts.

So what is Azure Firewall?

Image Credit – Microsoft

Firstly it is sold as a service, so you don’t have to spin up any infrastructure to host it, you don’t need to patch it, HA and scalability is baked into the service.  It provides filtering at Layer 3 and Layer 7 of the network stack.  It controls outbound traffic from your network.

I think its important to call this out, the Azure Firewall will allow you to filter traffic that is leaving the subnet it originates on… it does not provide any sort of inbound NAT or publishing rules, so you can’t set an Azure Firewall in-front of your web server and expect inbound traffic to flow through it.

The positive for me here is that Microsoft have provided a native solution to filter outbound access from your VMs.  While traffic filtering outbound was always possible via NSGs it was limited to Layer 3.  For example, if i wanted my VM to have https access through to only *.microsoft.com, my only options were to permit https access to everywhere, or come up with every IP used by *.microsoft.com and add it to a NSG and of course maintain it.  This was a no go and meant third party solutions were needed.  The Azure Firewall now provides a way to do this and its simple to use too.

Now the negative, to force traffic to the Azure Firewall you need to setup a route on your subnet that will direct traffic to the Azure Firewall.  The easiest way to do that is to send all traffic not local to the Vnet to the Azure Firewall by using 0.0.0.0/0 (everything) as the scope of the route.  This is were things could start to break for you, if you’ve a public IP attached to, or publish out a VM via a load balancer the route above will break this, all internet traffic will be directed to the Azure Firewall and asymmetric routing will kick in.

So lets say you publish your web server via an external load balancer, if you went with the default route approach above you’d lose access to the your web server.  This to me is a big limitation and a potential show stopper to deploying an Azure Firewall.  Now there is a solution for this scenario, you could use an Application Gateway (with or without WAF) to publish your site and this would resolve the issue. By ensuring the subnet for the App Gateway doesn’t have a default route pointing to the Azure Firewall the web server could respond to requests coming in via the App Gateway and your site would still be available.

While this offers a solution for a web server it wouldn’t work for non http/https protocols, its also expensive (now you’re paying for an Azure Firewall and App Gateway) and I’m not an App Gateway fan – I’ve found they are slow to deploy/update and the 20 listener limitation reduces scalability in some scenarios.

You can limit the servers that route outbound traffic through the Azure Firewall by placing those servers on the same subnet.  This could help you in the scenario say for PCI regulation whereby you need to permit internet access to a very small subset of websites for a group of servers in scope for PCI.

To summarise…

Positives

• Layer 3 and Layer 7 outbound filtering
• Azure Firewall seems to be quick to deploy and update – slower than NSGs, faster than App Gateway
• Its a native solution – supports ARM deployment and PowerShell and will work will with automation tools!!
• Its a service – nothing to manage (but the rules), built-in HA and scalability
• Centralised logging capabilities – gives much better visibility of what traffic is flowing out of your network
• Centralised policy for outbound access

Negatives

• It only filters outbound traffic
• Logical inline deployment will impact inbound access to your VM (if currently uses a ELB or public IP)
• I think its quite expensive (I won’t be using it for my labs!)
• There doesn’t seem to be a way to stop the service to prevent incurring charges – I would like a way to stop the service similar to the capabilities of an App Gateway (vote here to request the addition of this capability)

Of course this is only a Public Preview at this point so I’m sure the offering will continue to mature.  Overall I think the Azure Firewall is a welcome addition and its overdue but I don’t think its a perfect solution yet!