Azure Networking : Building a DMZ and adding Packet Inspection to all Traffic


The last week I’ve been putting down a sweat on getting the following “basic” design working.


What do we see here? A virtual network with three subnets. The subnet “SUBNET000” will act as our “External DMZ”. We’ll put the Firewall (and other security related appliances) in here. The other subnets can fulfil different roles, as you want… Let’s imagine that the “SUBNET001” is our “Internal DMZ” and the “SUBNET002” is our “Server Network”.

And what do I want to achieve today? I want all traffic to flow through the firewall. This so I can control / inspect all flows and act accordingly. As a basic test, I want to be able to ping from (subnet001) to (subnet002) and I want to be able to browse to “” (internet) from (subnet001). Both tests need to be performed with the firewall als virtual network appliance routing all traffic. This is needed, as otherwise the whole test is useless from a security perspective. 🙂 If I can do those two things, then I can prove that the you can control / inspect all traffic from your Azure network.



The Setup

How will we be achieving this? We’ll be creating a VNET with three subnets. We’ll deploy a firewall in the first subnet and a small server (per subnet) in the two other subnets. Then we’ll add a user defined route (UDR) that will point to the firewall (virtual network appliance).


Practically Speaking

So I create three resource groups  ;

2016-03-14 12_59_00-Settings - Microsoft Azure

The “kvaes-test-network” resource group will contain the virtual network and the user defined routes. The “kvaes-test-firewall” will contain the firewall and the “kvaes-test-servers” will contain the two servers.


FYI – Normally I would also add a resource group for storage, but I haven’t done that in this case to keep it a bit more condensed and enable me to cleanup per resource group. This as I’ve scratched and rebuild this demo environment A LOT the last days. 🙂



  • Create the virtual network
    2016-03-14 12_57_32-Subnets - Microsoft Azure
  • Deploy two small ubuntu systems in SUBNET001 en SUBNET002
  • Deploy a firewall from the marketplace into SUBNET000
    2016-03-14 12_58_12-Settings - Microsoft Azure
  • Ensure that there are NO network security groups in place. External traffic should be routed via a LoadBalancer through the firewall!
  • Enable the NIC Of the firewall so handle IP Forwarding. This needs to be done on Azure level. And maybe even on appliance level... (previous blog post)
  • Create a routing table per subnet and add the user defined routes to them. Then attach the routing table to per subnet (SUBNET001 & SUBNET002). Do not add a routing table to SUBNET000! (script)
    2016-03-14 12_57_50-Settings - Microsoft Azure


Let’s test!

So now let’s put this all to a test… 2016-03-14 13_13_29-kvaes@ubuntu01_ ~

That went smooth… and what does the firewall say?

2016-03-14 13_14_20-Barracuda NG Admin 6.2 - root @ FirewallA - Firewall _ History

So our plan works! Enjoy building on top of this starting point… Enterprise networking hardening in Azure is now possible.



  • At the moment of posting, it is not possible to add a kind of “catch all” loadbalancer to serve as the entry point for your UDRs (user defined routes). An alternative is in the works for this and should arrive in several months… For the time being, you can work your way around this, like the creative implementation as done by Barracuda.
  • Another “gotcha” is that you currently cannot add a UDR to a Virtual Network Gateway. This has some serious consequences in regards to VPN, and more importantly ExpressRoute, traffic. So please add your vote for this enhancement!
  • Network security groups are a great addition to create a kind of “back-to-back” firewall setup. Though be aware that this greatly increases the complexity!



  • It is possible to create a DMZ-alike structure in Azure. You can now also do “IPS” (intrusion protection system) on all you Azure traffic.
  • Networking in Azure differs quite a bit from traditional networking. The network virtualization enables a lot, though it makes things weird at times… For instance ;
    2016-03-14 13_24_41-
    Notice the MAC addresses… And it still works? 😉 It’s due to the network virtualization stack. The packets are encapsulated, so you cannot see the physical layer.

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.