Setting up a DMZ in Azure? Firewall or Network Security Groups?

A question that often pops up is ; “How can I configure secure network zones in Azure?”

There are two ways towards tackling that question ;

  • Traditional implementation with Firewall appliances
  • Azure’s “Network Security Groups”

Both deployment models have their advantages and disadvantages…

Traditional Firewall
A traditional firewall deployment will act as central gateway through which all traffic needs to flow. This implies that the firewall is directly connected to all network zones. In the drawing below, we can see that the firewall is connected to three network zones; “Internet”, “Web Servers” & “Database Servers”. So from a physical networking point-of-view, the firewall has a seperate network connection to each of the three network zones.
When we would translate this model to Azure, then we would need to have a virtual machine with three network interfaces, where each network interface would provide a link to a seperate virtual network. In addition, the default gateway for each virtual network would need to be overriden to point to the firewall.

So far so good? Now be aware that the amount of network interfaces is limited by the size of your virtual machine. By default you will only get one network connection. The cheapest virtual machine to get two network connections is the “A3” (200€/month), four interfaces will need at lest the “A4” (400€/month), where for eight interfaces you will need to look towards the “D4” (811€/month) and for the maximum of sixteen you will need a “D14” (1,512€/month). So this isn’t cheap…

Now bear in mind, that you will only have paid for the machine itself… When we look towards the marketplace in the new portal, then we see appliances that can be purchased in a “pay-as-you-go”-manner. If we pick CheckPoint here, we can see that the list price here varies from ;

  • A3 : 1665,10€ => 2 NICs
  • A4 : 2892,45€ => 4 NICs
  • D4 : 3003,26€ => 8 NICs
  • D14 : 5489,08€ => 16 NICs

When looking towards such an outcome, most customers will say “Thank you very much, but no thank you!” in those sessions. And in all honesty, I fully comprehend the reaction, where I would say the same thing in their situation. Though, that does not solve their initial puzzle…

Network Security Groups
The alternative is setting up NSGs (Network Security Groups). Consider these a basic firewall implementation like the Windows Firewall or IPTables in *nix. How is it positioned by Azure?

A Network Security Group consists of a set of access control rules that describe traffic filters. These can be associated with a virtual machine or a subnet in the same region. The rules defined in the Network Security Group act as filters. On the ingress path they are applied before traffic enters the VM. On the egress path, they are applied after traffic leaves the VM. In short these rules are applied at the infrastructure level which can’t be altered by user processes or even the OS running in the VM. When the Network Security Group is associated with a subnet it applies to all the VMs in the subnet. Any change made on the Network Security Group is immediately is applied to all VMs in the subnet. Source


So with NSGs, you are capable of configuring a DMZ alike situation… What are the limitations?

  • Maximum 100 NSGs per subscription. Maximum 200 rules per NSG.
  • It only covers VM in a virtual network. So when you select “West Europe” instead of “MyPrivateVirtualNetwork”, then you cannot apply them.
  • The configuration can only be done via PowerShell at the moment. But as we all know, the pace of Azure travels at Warp9, so a UI will come…)

So what Can I configure?
Some important aspects of the Network Security groups include:

  • The rules contain a 5 tuple (Source IP, Source port, Destination IP, Destination port, protocol).
  • The rules are stateful. This means if there is an inbound rule that allow traffic on a port (e.g. port 80), a matching rule on the outbound side is not required for the packets to flow on the same port.
  • Every Network Security Group contains default rules that allow connectivity within the Virtual Network and Outbound access to Internet . These default rules can be overridden by the user rules.
  • The rules are processed based on priority. Rules with small (meaning higher priority) values are processed before rules with larger (meaning lower priority) values.
  • Azure provides defaults tags such as INTERNET and VIRTUAL_NETWORK that refers to the Public IP Address space outside the Virtual Network and customer’s entire network address space respectively. The tags can be used as part of an access control rule.

Comparing both
So when do I choose one over the other? It basically comes down to this…

  • When you only need basic features, want to restrict your budget and you are not afraid of powershell… Go for Network Security Groups.
  • When you need a lot of Enterprise features (deep packet inspection, central management, …) or pass beyond the basic featurs towards the things a “Next Generation Firewall” offers, then you need to go for a full blown firewall implementation.

3 thoughts on “Setting up a DMZ in Azure? Firewall or Network Security Groups?

  1. Sorry to say, but the “traditional firewall” section here is VERY wrong. Rule #1 when starting to play with cloud networking is “forget what you knew about networking” 😉

    All traffic in Azure is virtualized, it all goes through the same distributed virtual switch (plus massive infrastructure including en/decapsulating) and splitting traffic to multiple NICs by no means helps to separate it (really really). Next thing – UDR (User Defined Routing) in Azure does not work the way one expects. Guess what – you CANNOT route through an IP address in the same subnet as the source, but you need to put a firewall in a separate subnet.

    To conclude – putting a firewall in Azure does not require more than one NIC (if your favorite firewall vendor cannot cope with it – time to move to something more “cloudy”).

    1. Do note this article is almost 3 years old… As I produce quite a lot of content, it’s quite hard to keep everything up-to-date. That’s the purpose of documentation. That’s the reason for open comments & the “The cloud moves fast!”-disclaimer on the side. 😉

      Though you are correct that a single legged deployment is possible. Since then a lot has changed. Where a single legged deployment will even simplify a lot of workloads where otherwise you would need to incorporate SNAT, or you would trigger the typical anti-spoofing mechanisms of your NGFW.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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.