Microsoft blogged a couple of posts in the last month to announce some interesting news about Azure Firewall, a resource that I’m using with every customer that I dealt with in the last year.
- New Azure Firewall certification and features in Q1 CY2020
- Azure Firewall Manager now supports virtual networks
Azure Firewall Manager (Preview)
I first played with Azure Firewall Manager in the Secure Virtual Hub preview. Now the feature is in preview with the “network SKU” of Azure Firewall. The concept starts with Azure Firewall Manager, an Azure Portal GUI that isn’t a resource; it’s a way to centrally manage one or more Azure Firewall resources in one region or in many regions.
Azure Firewall Manager does control a new top-level resource: a firewall policy. Policies move the management of Azure Firewall configuration and rules from the firewall resource to the policy resource. You can create a simple hierarchy of policies.
For example, I find myself creating the same collections/rules in every Azure Firewall; if a customer has 3 network deployments around the world with identical base requirements then you can create a “parent” policy. Then you can create a child policy for each firewall instance that is a child of the parent; that means it inherits the current and future configurations of the parent policy. And then you associate the child policy with the correct firewall. Now you do the network-specific changes in the child. Any future global changes go into the parent, and they will inherit down to each firewall.
Cool, right?
IP Groups (Preview)
This is another cool top-level resource. Let’s say I’m managing an Azure Firewall with a site-to-site network connection. There’s a pretty good chance that I am constantly creating rules for specific groups of addresses, sets of networks, or even all the “super-nets” of the WAN. Do I really want to remember/type each of those addresses? Surely a mistake will be made?
IP Groups allow you to create an abstraction. For example, I can put each of my WAN super-nets into an IP Group resource called wan-ipg. Then I can use wan-ipg instead of listing each address. Nice!
Support for TCP/UDP 65535
One of those base configurations that I’m constantly deploying is to enable Active Directory Domain Services (ADDS) domain controllers to replicate through the Azure Firewall. If you go look at the TCP/UDP requirements you’ll find that one of the rules requires a huge range, with the high port being 65535. However, Azure Firewall only supported up to TCP/UDP 64000. It did not affect me, but there were reports of issues with ADDS replication. Now you can create rules up to the normal maximum port number.
Forced Tunnelling Support
This is for those of you who live in 1990 or have tinfoil on your heads. Now you can force all outbound traffic to go back to on-premises instead of to the Internet. I guess that this one is for the US government or someone with equally large purchasing power (influence).
Enable Public IP Addresses in Private Networks
I’m working with a customer that has used public IP addressing behind their on-premises firewall. One of my colleagues at work has a similar customer. I know of others with the same sort of customer.
Azure Firewall has not been compatible with that configuration. Imagine this:
- The customer has a public IP range for their on-premises LAN – no NAT rules on the firewall.
- They have a site-to-site network connection to Azure.
- An Azure Firewall sits in the hub of a hub and spoke network – all ingress and all egress traffic must pass through the firewall.
- A service in an Azure spoke tries to communicate with something on-premises on one of those public IP addresses.
And that’s where it all goes wrong. Azure Firewall sees that the destination is a non-RFC1918 IP address (not 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and forcefully SNAT’s the packets to the Internet, and the packets never reach the on-premises destination.
With this update, you can use PowerShell/JSON to configure public IP ranges that are to route via the AzureFirewallSubnet (propagated routes from GatewaySubnet) and not to the Internet.
ICSA Labs Corporate Firewall Certification
Certifications are good, and some customers probably compare using these sorts of things.