
close
close
Chance to win $250 in Petri 2023 Audience Survey
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:
An Azure DMZ made from user-defined routes, a virtual appliance firewall and NSGs (Image Credit: Microsoft)
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:
The Azure virtual network subnets (Image Credit: Aidan Finn)
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.
The user defined routes for a DMZ in Azure (Image Credit: Aidan Finn)
Route Name | Address Prefix | Next Hop Type | Next Hop Address |
Network | 10.0.0.0/16 | Virtual appliance | 10.0.0.4 |
Everywhere | 0.0.0.0/0 | Virtual appliance | 10.0.0.4 |
FrontEnd | 10.0.1.0/24 | 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 | 10.0.0.0/16 | Virtual appliance | 10.0.0.4 |
Everywhere | 0.0.0.0/0 | Virtual appliance | 10.0.0.4 |
BackEnd | 10.0.2.0/24 | 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)
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)
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:
More in Microsoft Azure
Microsoft Introduces Fully-Managed Azure Load Testing Service for Developers
Feb 2, 2023 | Rabia Noureen
Azure Native New Relic Service Provides Full Stack Observability To Boost Digital Transformation
Jan 25, 2023 | Rabia Noureen
Microsoft to Roll Out EU Data Boundary Plan for Cloud Services on January 1
Dec 15, 2022 | Rabia Noureen
Most popular on petri