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:
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.
A single virtual network is created in the resource group. There are three subnets:
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:
Note that the firewall will be deployed with a reserved private IP address of 10.0.0.4.
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:
|Next Hop Type
|Next Hop Address
And here are the rules for the back-end subnet, including the optional third rule called BackEnd:
|Next Hop Type
|Next Hop Address
Associate the front-end routing table with the front-end subnet and the back-end routing table with the back-end subnet.
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.
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:
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:
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: