Firewall Options

We are not short of options to deploy network security in the form of a firewall in Azure:

• Network Security Groups (NSGs): A Layer-4 policy that is associated with subnets in a virtual network (VNet).
• Web Application Firewall (WAF): A Layer-7 firewall for HTTP and HTTPS services that are deployed on the Medium or higher sizes of the Azure (Web) Application Gateway.
• Network Virtualization Appliances (NVAs): Linux virtual machines that contain firewall software from third-party vendors such as CheckPoint, Watchguard, Cisco, and so on.

And earlier this year, Microsoft released a preview of the Azure Firewall, a new Azure firewall service. Unlike NSGs, Azure Firewall is intended to be a centralized deployment. And unlike the WAF, Azure Firewall is not instance-based; it operates as a true PaaS feature and doesn’t bother you with worrying about deployed instances. Instead, the Azure Firewall automatically scales under the covers to deal with your workloads. And unlike NVAs, you won’t need to license a third-party service to use the WAF.

Azure Firewall

The Azure Firewall is not a budget service; it will start at over $900 per month for a deployment, plus $0.03 per GB of inbound/outbound of data that is processed. This will give you a clue as to how Azure Firewall should be used.
Very often in the cloud, firewall services are distributed. It’s not uncommon to see NSGs on every subnet and a WAF for every application. Azure Firewall is intended to be deployed in a hub VNet that is managed by network admins or IT security. Applications can then be deployed into spoke virtual networks without a public IP address.
Note that Azure Policy could be used to restrict the creation of public IP addresses.
Each of the spoke networks can peer with the hub with IP forwarding enabled from the hub into the spoke VNets; this will allow the firewall to forward traffic into applications running in the spokes. And now, the Azure Firewall can control traffic into and between the spoke VNets.

Note that routing tables will be deployed in the subnets of the spoke VNets to direct all outbound traffic through the private/internal IP address of the Azure Firewall “appliance”.

Features

The Azure Firewall is not instance based. The goal is that you deploy it and configure it and let Azure worry about sizing – therefore you pay for data processed. It is a highly available service that should scale to match the requirements of the applications that it protects.
By default, the Azure Firewall blocks all traffic, inbound and outbound. Outbound traffic can be allowed based on IP address, CIDR block or HTTP/HTTPS fully qualified domain names (FQDNs). All traffic leaving the spoke VNets will be translated to the Standard tier public IP address of the Azure Firewall, allowing you to identify that traffic in remote networks.
Inbound traffic can be translated to private IP addresses that are protected by the Azure Firewall – this is a new feature that was not available in the preview. Destination Network Address Translation (DNAT) is what this feature is called, and you will see the phrase “DNAT” throughout the Azure Firewall documentation. It is simply referred to as NAT in the Azure Portal.
All events that happen are integrated into Azure Monitor. You can archive these events in a storage account, Log Analytics or stream the events to an Event Hub.

Some Issues Remain

The Azure Firewall preview was a limited one. I thought Microsoft would launch a public preview at the Ignite conference, so I was surprised to see it have become generally available. There are a few kinks, but this is The Cloud and things should improve quickly:

• Just-In-Time VM Access: JIT VM Access is incompatible with the Azure Firewall. Any enabled machines should bypass the Azure Firewall via the route table(s).
• Global VNet Peering: A spoke VNet must be in the same region as the Azure Firewall.
• TCP/UDP Only: Filtering rules must be for UDP or TCP only.
• TCP 80 and 22: This one is puzzling, but Microsoft intends to fix is “very soon”; you cannot use DNAT rules to translate from TCP 80 to TCP 80 or from TCP 22 to TCP 22.
• ICMP via Command Line: You cannot configure ICMP rules using Azure PowerShell or CLI, but you can use the Azure Portal.
• FQDN and Protocol/Port: You must enter protocol:port, such as HTTP:80 when specifying an allowed outbound FQDN.
• Moving: This one is a blast back to a now-gone problem with managed disks; you cannot move the Azure Firewall to another resource group or subscription.

Early Experience

The Azure Firewall is pretty simple to deploy. I think that the main thing to consider is that this is intended to be a centrally deployed security service, so you must plan out your network architecture. Applications will be deployed into spoke VNets, possibly with application gateways and/or load balancers, and even with the Layer-7 WAF, but with private IP addresses. Routing tables will have to be deployed to control the flow out outbound traffic through the Azure Firewall, and this firewall will also control the flow of traffic between applications. And yes, NSGs will still play a role, however, Application Security Groups will probably flatten deployments that previously might have contained many subnets.
The example deployment documentation that Microsoft has shared is pretty good – you can see that some minor UI stuff changed at the last second. What I think is missing now are reference architectures to display end-to-end architectures that Microsoft will be recommending for different patterns involving the Azure Firewall.