Microsoft Azure

Implementing a DMZ for Microsoft Azure Virtual Machines


In this post I’ll show you how you can create a DMZ for hosting an n-tier application based on Azure virtual machines, using a combination of Azure features: a multiple subnet virtual network, a firewall appliance from the Azure Marketplace, network security groups, and user-defined routing.


In this article I’ll be using a design that was discussed in “Designing a DMZ for Azure Virtual Machines.” The specific design in question uses:

  • Virtual network: The network is split into three subnets, one for security, one for web servers, and the third for backend servers.
  • Virtual firewall appliance: This is a third-party firewall that runs in a special Azure virtual machine that can be deployed from the Azure Marketplace — check with the original vendor on how they license or bill for the appliance in addition to the virtual machine charges. The firewall appliance provides application-layer security between the Internet and the service, and between the networks and machines within the service.
  • Network security groups (NSGs): NSGs are used to create protocol and port rules to enforce routing via the firewall appliance so that firewall rules and inspection are always used.
  • User defined routing (UDR): We need to override default routing between the virtual network subnets and route via the virtual firewall appliance.
An Azure DMZ made from user-defined routes, a virtual appliance firewall and NSGs (Image Credit: Microsoft)
An Azure DMZ made from user-defined routes, a virtual appliance firewall and NSGs (Image Credit: Microsoft)

Resource Group

Normally, I like to wrap up all components of a service in a single resource group and then create a resource group for the online service. I’ve created one called PetriDMZ.

Sponsored Content

Read the Best Personal and Business Tech without Ads

Staying updated on what is happening in the technology sector is important to your career and your personal life but ads can make reading news, distracting. With Thurrott Premium, you can enjoy the best coverage in tech without the annoying ads.

Virtual Network

A single virtual network is created in the resource group. There are three subnets:

  • Security: This subnet is the public face of the service and is where the firewall virtual appliance will be located.
  • FrontEnd: The web servers of the service run in this subnet.
  • BackEnd: Application and database servers run in this completely isolated subnet.
The Azure virtual network subnets (Image Credit: Aidan Finn)
The Azure virtual network subnets (Image Credit: Aidan Finn)

User Defined Routing

Our goal is that all traffic must route via the firewall in the security subnet. This requires one routing table for the back-end subnet and another for the front-end subnet with at least two rules:

  • Override internal routing: We must override the default routes between the front end ( and the back end ( subnets with a rule for the virtual network 10.
  • Override global routing: All traffic to all other destinations ( must be routed via the firewall, too.

Note that the firewall will be deployed with a reserved private IP address of

The user defined routes for a DMZ in Azure (Image Credit: Aidan Finn)
The user defined routes for a DMZ in Azure (Image Credit: Aidan Finn)

With the above configuration, no machine can talk directly to a machine in a different subnet. Even machines in the same subnet will communicate via the firewall, which is probably desirable, but you can override this behavior with an additional rule to allow intra-subnet traffic to route directly within the subnet.

Here are the rules for the front-end subnet, including the optional third rule called FrontEnd:

Route Name Address Prefix Next Hop Type Next Hop Address
Network Virtual appliance
Everywhere Virtual appliance
FrontEnd Virtual network N/A

And here are the rules for the back-end subnet, including the optional third rule called BackEnd:

Route Name Address Prefix Next Hop Type Next Hop Address
Network Virtual appliance
Everywhere Virtual appliance
BackEnd Virtual network N/A

Associate the front-end routing table with the front-end subnet and the back-end routing table with the back-end subnet.

Associate a routing table with a subnet (Image Credit: Aidan Finn)
Associate a routing table with a subnet (Image Credit: Aidan Finn)

Network Security Groups

Next, we will create simple network security groups (NSGs), each with a single rule, whose purpose is to protect against manual error. Security is actually being provided by the firewall. The NSG rule puts in a simple filter to prevent any traffic from the Internet-reaching machines in either the front-end or back-end subnets; everything must route vie the security subnet.

Create two NSGs, one called FrontEnd and one called BackEnd. Each will be configured with an identical single inbound security rule, as shown below.

Creating a NSG rule (Image Credit: Aidan Finn)
Creating a NSG rule (Image Credit: Aidan Finn)

Associate the front-end NSG with the front-end subnet and the back-end NSG with the back-end subnet.

There is a chance that you’ll decide to extend the rules in the NSGs to provide an extra level of protection between the front-end and back-end subnets, beyond what the firewall appliance offers. If so, you can:

  • Override the default rule to block all VNet-internal traffic, which is allowed by default.
  • Create additional rules that allow each acceptable application protocol.

Firewall Appliance

The exact instructions for deploying and configuring your virtual firewall is provided by the vendor of the virtual appliance.

There are three considerations in this design:

  • The virtual appliance is deployed into the security subnet.
  • You will reserve the IP address of for the virtual appliance.
  • You must enable IP forwarding for the virtual NIC of this virtual appliance to allow it to route and redirect traffic.

In my example, I’ve used Azure V2 or Azure Resource Manager (ARM). The following piece of PowerShell will be used to enable IP forwarding for a virtual machine called PetriDMZFW in the PetriDMZ resource group:

$RgName = “PetriDMZ”

$VMName = “PetriDMZFW”

$NicName = ((Get-AzureRmVM -ResourceGroupName $RgName -Name $VmName).NetworkInterfaceIDs).Split("/")[-1] | Out-GridView -Title "Select a NIC to configure forwarding ..." –PassThru

Next, you’ll get the configuration of that NIC using the following line:
$NicConfig = Get-AzureRmNetworkInterface -ResourceGroupName $RgName -Name $NicName

And finally, enable IP forwarding:
$NicConfig.EnableIPForwarding = $true

$NicConfig | Set-AzureRmNetworkInterface

There are two remaining steps:

  • Create and edit the NSG of the security subnet to allow your desired inbound traffic from the Internet.
  • Use the administration tool of the virtual firewall appliance to create all of the external and internal firewall rules that your n-tier application requires.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (1)

One response to “Implementing a DMZ for Microsoft Azure Virtual Machines”

  1. bamather

    I'm a little confused on how to create firewall rules when there are no "zone". When i create a rule I use the interfaces as the zone with my on-prim fortinet, but when I want a webserver in the DMZ to talk to my application server in the data subnet how would i create the rule. The interface for incoming and outgoing would be the same interface.

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.

Download this eBook!

External Sharing and Guest User Access in Microsoft 365 and Teams

his eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure. The eBook will also outline some of the major decision points across four general-purpose guest access policy scenarios for how an organization can set this up with standard licensing.

Download Now

Sponsored By