5 Advantages to Using Azure Firewall Over Azure Network Security Groups

Microsoft Azure provides two different methods of creating network security rules: Azure Firewall and Network Security Groups (NSGs). In layman’s terms they do basically the same thing: blocking or granting inbound and outbound connectivity. However, beyond that basic description, they are very different tools, and Azure Firewall is by far the more capable of the two. Table 1 below shows the feature differences.

Table 1: Feature comparison between Azure Firewall and Network Security Groups

Azure Network Security Groups

The biggest advantage to NSGs is the cost of entry, which is free. While free is always attractive, NSGs don’t offer much of the flexibility which Azure Firewall offers. This limited supported feature set works for some companies; however, many companies need a more robust product to allow and deny access to and from their virtual machines within the Microsoft Azure environment.

NSGs allow for basic granting and denying access to and from resources within the Microsoft Azure environment. They allow you to build these rules based on the IP addresses or service tag of the source and destination machines as well as the protocol and the various port numbers. However, NSGs can only use IP addresses to grant or deny access. If, for example, a company had an Azure Virtual Desktop (AVD) environment and you wanted to allow internet access from that environment but you wanted to block access to Facebook from the AVD platform, you’d have to enter in the IP address ranges which Facebook uses for their website. This would require some research to find out, and whenever Facebook added IP address ranges, you’d need to manually add them. With Azure Firewall you could simply enter the website URL www.facebook.com.

Azure Firewall

While Azure Firewall does have a higher cost of entry than NSGs, the benefits it offers make the cost acceptable pretty quickly.

FQDN Support

One massive difference between Azure Firewall and NSGs, which I touched on above when describing the limitations to creating rules with the latter, is that you can use full qualified domain names (FQDNs) when creating rules. This allows you to grant or deny based on network names. Using FQDNs allows you to create complex criteria with fairly simple rules. A perfect example is the rules to support Windows activation, which you can see in Figure 1.

As you can see in Figure 1, enabling Windows activation in Azure Firewall requires five basic rules to allow access to port 80 and 443, and the final rule for KMS which requires several ports. To create this kind of rule using NSGs you’d need to look up all the possible IP addresses for these various domain names and then build rules for each IP address, and if Microsoft changes the IP addresses behind those domain names, you would need to manually update the NSG rules. The Azure Firewall rules, by contrast, just continue to work.

Rule Collections

Azure Firewall supports what Microsoft calls rule collections. These rule collections allow you to group the rules together to make their long-term management easier. An example of this would be outbound firewall rules as shown in Figure 2. The rules shown in Figure 1 would be placed in a rule collection called WindowsActivation, with other permitted internet access, such as access to the public DNS servers, access for the applications to use SendGrid and access to the public NTP servers all contained within the Internet rule collection. These various rule collections are then bundled together in a single rule collection group. Rule processing priority is handled at the collection level, with the order of processing being managed by the user who configures the Azure Firewall Policy containing the rule collections. This gives you, the administrator, the ability to create rules for different groups, subnets, etc., and to manage them in one interface quickly and easily.

Single Rule for Two Protocols

While both NSGs and Azure Firewall support creating rules which use the network protocol Any (which covers TCP, UDP, and ICMP), the interface for NSGs only supports selecting one protocol (including Any), whereas the interface for Azure Firewall supports selecting as few or as many protocols as needed for the rule, as shown in Figure 3.

This becomes very handy when creating rules for services that need to be able to use multiple protocols, such as DNS, which can support using both TCP and UDP on port 53. By supporting a subset of the protocols, this reduces the number of rules that are needed, as well as reducing network exposure by not selecting Any.

Application Rules

Azure Firewall supports more rule types than just TCP and UDP traffic. Application-specific traffic can be granted or blocked as needed for applications which require it. This is different from TCP or UDP traffic. As an example, putting Azure Kubernetes Services (AKS) behind Azure Firewall where you have TCP port 443 open isn’t good enough. AKS wants application rules there where the firewall checks to make sure that the connection is actually using the https protocol and not just a socket connection to the destination.

Azure Firewall supports application rules using either http or https as well as mssql (for SQL Server database connections) and allows you to define which port will be used in case you want to use a TCP port other than 80 (for http), 443 (for https), or 1433 (for mssql). While not all applications require this level of packet inspection, some do, and the Azure Firewall gives you this capability. It also includes the ability to perform TLS inspection, which will decrypt and inspect the https traffic which is passing through the Firewall to ensure it is valid traffic. The TLS Inspection option is a Premium SKU feature, so it is not available in the Standard edition.

Policy Inheritance

Azure Firewall supports policy inheritance for firewall policies. This means that you can create one global policy that will affect every policy within your environment. When policies are created, you can specify another firewall policy as the parent of that policy, as shown in Figure 4. This means that any rules created in the parent policy will automatically be applied to the child policy, and any changes made to the parent will automatically be picked up by the child policy (and the firewalls which are using the policy) automatically.

As you can see from the warning in Figure 4, parent policies need to be placed in the same Azure region as the child policy. However, Azure Firewalls can use policies in any region, so you can place your policies in your production region, or a third region outside production or disaster recovery (DR) and have your production and DR firewalls use these policies.

Generally, it is recommended to put the policies in a third region and not your production or DR region. That’s because if you put the policies in your production region, and that region is going offline, and then there’s a problem with your DR policy, you can’t fix it. If you put your policies in your DR region, you now have a dependency between production and DR, where production relies on the DR site and if DR goes down then you can’t edit the production site’s firewall policy. If the policies are in a third region, and either region goes down, then the policies are still available. If the third region goes offline, then no, you can’t edit the policies while it is down, but given that your production site is still online, that shouldn’t impact production at all. And given that the odds of two Microsoft Azure regions going offline at once are infinitesimally small, this is an acceptable risk. While this does put the company’s resources in a third Azure region, this is done for a good reason—increased availability—with no financial cost to doing so.

NSGs are listed in Table 1 as “sort of” having policy inheritance. While NSGs don’t have actually policy inheritance, you can add two different NSGs to a VM. This is done by applying one NSG to the VM’s network interface card (vNIC) itself, and a second NSG to the Subnet that the VMs vNIC resided in. This gives the same basic effect that the Azure Firewalls have with policy inheritance, however done in a very different way.

Selection

As you’ve seen through this article, while Azure Firewall has a cost of entry, it provides a lot of features that NSGs lack: FQDN support; options that allow for easier rule management; and application-level network rules in addition to TCP/UDP-only rules. So, while both NSG and Azure Firewall support the same basic function, the advantages of the latter allow for a lot more flexibility in managing network traffic in an Azure setting.

So, should you use NSGs or Azure Firewall in your Azure environment? NSGs are pretty compelling because of the cost of entry. However, I would argue that in most cases, it will make sense to deploy Azure Firewall and put all of the resources within your Azure environment behind the more flexible protection that Azure Firewall provides. Many companies even combine NSGs and Azure Firewall, using the former to block or allow internal connections to services from other machines within the Azure environment and using the latter to protect the connections between the Azure environment and the public Internet.

It all comes down to cost. In most cases, Azure Firewall will prove to be worth it, based on the additional capabilities I’ve described in this article. But each administrator will have to weigh its organization’s needs and decide for themselves.