Designing Azure Networks – Part 2 – Security, DMZ, Perimeter N/W, PaaS, web app

This article is part of a larger series of articles titled “Azure Networks for Architects“.

In this article, we will analyze the options available for building a DMZ or a perimeter network on Azure while using PaaS services like Azure Web App. Let’s start with a network design and see what’s wrong with it.


In above design, users access a typical website hosted on Azure Web App (marked 1) which in turn need to access a SQL Server VM hosted in an Azure vNet. Azure web app is connected to Azure vNet using P2S VPN (marked 2). The Azure vNet in turn is connected to on premise resources using VPN. As usual, there is a dedicated subnet for hosting VPN gateway on Azure vNet.

Above a typical scenario that is recommended on Azure (and many have implemented it) where a PaaS service like Azure Web App can access backend resources (like SQL DB) using vNet connectivity and even on premise resources (when vNet is further connected to on prem n/w via VPN).

However, this network design has a couple of security flaws which is unacceptable in many scenarios.

Flaw # 1: Unrestricted access to public facing resources

If you observe above design, traffic from internet to Azure Web App goes uninterrupted. Azure web app does not offer any mechanism where we can apply our custom security policies to incoming traffic. For example, what if we don’t want to expose Azure Web App to internet? We don’t even have an option to turn off public endpoints. Threats like DDOS attacks or IP spoofing go simply unchecked. Wait… someone can say that Microsoft writes that they do have security infrastructure in place for attacks like DOS. Well, read again. The security checks that Microsoft provides are for “their resources” and not “your resources”. This is a very common misconception to misread Microsoft’s own security as Microsoft providing security for customer’s endpoints! No, no one provides anything for free. Though Microsoft provides security but that is very basic. For example, Microsoft will monitor if any other tenant is trying to attack your system from within Azure and prevent it (but it doesn’t protect the attack originating from outside Azure). This is the statement that you need to look for “Windows Azure’s DDoS protection also benefits applications. However, it is still possible for applications to be targeted individually. As a result, customers should actively monitor their Windows Azure applications.“. See the term “also”. It means protecting customer’s apps is not its primary aim but yes, you will definitely et some basic protectuion if the underlying infrastructure is secured.

If you really want to use Microsoft services to prevent attacks, you need to pay for those services. Its called “Azure Security Center”. However, even Azure Security Centre doesn’t offer protection to Azure Web Apps unless you are in “Premium Plan with ASE”. In a nutshell, Microsoft has clearly written in its documentation (so don’t blame them) that they don’t provide protection for tenant’s endpoints. So, remember, you are very much prone to all kinds of attacks and only you… not Microsoft Azure.

Coming back to main point, the first reason why the above scenario is unacceptable is because “there is no control on inbound traffic for public facing resources“. Every organization wants to host a basic firewall (at minimum) that analyzes packets at different layers (especially higher ones) and allow/reject incoming traffic based on policies that your business demands and Azure web apps offer none. Such public facing resources become the weakest link or entry points for attacks into your overall system.

Flaw # 2: No/less cushion between public facing resource and backend resources

One of the important principle of security is called “defense in depth” or “castle” approach. This approach says that we need to increase the distance between the external world and protected resource and provide security by using multiple security controls at each layer. So, if your public facing web app is accessing a SQL Database directly, your SQL Database is at risk. This is also the reason why software design recommends using a “service layer” (not necessarily web service) where all access to backend resources happens via a dedicated set of services. However we don’t want to go into details of software design as it will dilute the topic so we’ll come back to networks.

When security is top priority, organizations maintain complete isolation between internal resources and external world. Below is very high level network design that many organizations follow for hosting public facing resources irrespective of the cloud platform capabilities.


Here are the characteristics of above design.

  1. The public facing resources are within a dedicated network of their own with firewalls and other security devices facing internet. This means that we have control over all of the traffic flowing in/out of public facing resources. We even have the capability to remove all of public facing inbound traffic or allow selective traffic based on security policies that organization wants and we don’t even have to touch the web resource. These controls can be placed on the network itself.
  2. Protected resources are in their own networks (DBs, DCs etc.). Here you’ll see two such separate networks. Whether to use an entirely separate network or use subnets goes into the discussion of performance vs security and my previous post talks about it.
  3. Communication between resources of two networks happen via gateways of the networks. The resources themselves don’t connect directly. If we compare with previous approach, in the flawed design, Azure Web app connected with the SQL Database via Backend vNet’s Gateway. There was only one entity involved in between web app and database. However, now there are two layers (gateway and security policies of DMZ vNet and security policies and gateway of backend vNet). So we have essentially increased the distance between public facing resource and protected resource and we get to deploy extra layers of security controls in between them. So this is better design from “defense in depth” point of view.

In above design the two problems that I mentioned are being addressed (control over inbound traffic and defense in depth).

The “How” on Azure?

Now, the question that remains is how to achieve above level of isolation on Azure networks while using PaaS services like web apps? There are two ways to address this problem on Azure. The first approach involves extra cost while other approach involves extra configuration (and a little bit of extra cost too).

Approach 1: Using Azure App Service Premium Plan
Azure app service offers different plans/editions. The highest of these is “Premium” plan. The premium plan can be used with two options:

  • using App Service Environment (ASE)
  • without using ASE

When we use ASE, the web apps are deployed within an Azure Network. This could be either your own existing n/w or you can create a new dedicated n/w. The app service servers “actually” become part of azure network (without using indirect mechanisms like P2S VPN). The main benefit of this approach vs using VPN is the fact that you can now use all the network security concepts of Azure vNets that you are familiar with (NSG, NSA, UDR…). So you can control the inbound traffic at fine grained level. You can perform deep packet inspection using advanced security appliances connected to your network.

When your app wants to connect to backend resources, you can connect the two networks without actually connecting your web app to backend n/w (you just need to connect the two networks via Gateways). However, this is a costly option just for implementing security and will increase the TCO of your solution. ASE will really be worth investing if you really need other ASE features too (like much larger scalability, bigger storage space etc.).

Approach 2: Using vNet to vNet connectivity
In this approach, instead of hosting web apps in ASE, we simply create a new dedicated network that is public facing and connect Azure Web App to this n/w via VPN as shown below. Notice that in comparison to previous design, the only difference is that the web app connects to DMZ vNet via VPN (and not actually part of it). But this small change makes a BIG difference. In this context, VPN is not same as actually being part of network because this approach still doesn’t provide the ability to control public facing inbound traffic. The web app still connects to internet without any checks and bounds (well, at least, not the ones that we wanted).


However, this design definitely solves the problem of defense in depth. Maybe in future Microsoft may provide capability where all web apps will be placed within a n/w (networks don’t cost us anything) or maybe provide extra capability to filter public inbound traffic.

Till then only ASE offers the uber features that an enterprise grade solution needs. Any non ASE based solution on Azure web app is not completely secure, at least in the books.

I hope you enjoyed this article. In the next article, we’ll take a look at other aspects of network designs.

This series is also mirrored at The links in this article below will be updated as and when new articles are posted.

-Rahul Gangwar


What are Networks?

This article is part of a larger series of articles titled “Azure Networks for Architects“. This is a “foundation” article that explains slightly different perspective about Networks and its underlying protocol stack. The article also provides a mapping between Azure constructs and general networking terms used.

Unless we are building a monolithic solution deployed standalone with no interaction to any other entity we are talking about a solution that involves “network” in them. Networks are very important while designing Azure Solutions. I can’t imagine any decent solution on Azure that does not involve having your own network unless we go for pure PaaS/SaaS based solutions.

“If two or more than two entities are connected with each other, they form a network”. Two things are important to understand here :
(1) “entity”: which means not necessarily computers
(2)”connected”: which means they are simply connected (they may not be actually communicating).

Avoiding much of complexity, in software application scenario, if you have two or more components deployed separately (typically presentation, service, business and data layers) you’d need to establish connectivity between them. You can do so by including them as part of a network. There are other non-network oriented ways for connectivity too but as I said, avoiding much complexity…

We see networks everywhere… at our home (wifi), at offices (Ethernet), Cell Phones etc. So, the fundamental process includes two steps:

  • Creating a network
  • Joining entities (typically compute devices) to the network

Since network is a grouping of devices for communication purpose, it is only natural to think that networks must be having a standard language that devices can use to communicate. Yes, you are correct. A network is incomplete unless we specify what language can devices speak in it. Every network supports a specific communication “protocol” that devices will use to talk between each other. So, that also means that every device that wish to connect to a network must understand that communication protocol.

There are different kind of network protocols and you choose one based on the requirements. For example, we use standards like GSM and CDMA for creating networks for cell phones, while we use TCP/IP for creating computer networks (both wifi and ethernet). These networks are different from each other, not only because they use different protocols (from software perspective), but also because they use different radio frequencies for communication. So, we need hardware (specific for a network) on the device that wants to join a given network. This is the reason why your phone probably has an antenna for connecting to GSM, a wifi adapter for connecting to computer networks and maybe another antenna for CDMA network. Coming back to point, computer networks are largely based on TCP/IP protocol suit (just like cellphones are GSM/CDMA based) and so are Azure Networks (did you really think of creating a GSM network on Azure 🙂 ). Going forward, I’ll use the term “device” instead of “entities” as we are moving closer to computer networks.

At this point I’d also want to give very minimal details about how protocols are stacked. These are basic but important concepts. There are many concepts that are “derived” and may not be written explicitly on documentation of product. These are few of those basic concepts from network perspective.

From user perspective, protocols start from layer 4 of OSI model on Azure. You don’t need to go into deep details of the layers of OSI (though some people claim they understand OSI…). What this means is following:

Layer 1:
We don’t have access to physical layer wires, wifi etc… they are managed by Microsoft.

Layer 2:
We don’t have access to data link layer… the software that interacts directly with physical layer. Networks are created on top of this layer and Microsoft did implement their own backbone network on this layer. But this network is inaccessible to cloud users.

Layer 3:
At layer 3 (network layer), we get the protocol called IP. Protocols like TCP, UDP and ICMP are implemented on top of IP. When “user” creates a network on Azure (called vNet in Azure terminology), it is created by Microsoft at layer 3 (the network (IP) layer). There are many versions of IP. Version 4 and Version 6 (IPv6) are of most interest. Microsoft creates vNet using IPv4. So, that means IPv6 is not supported on azure vNets as of today.

Network on Azure (vNet) is called virtual network because is implemented using software. This means that supporting IPv6 in future is merely a matter of upgrading software. In fact, support for IPv6 will be one of the few major announcements that you’d see in future. One question that may come into mind is, whether we can create VLANS on Azure or not? VLANS are also software created networks but they are created at layer 2 and the main purpose of VLANs was to join separate physical networks into one using software. But, on Azure, we don’t have access to layer 2 so we cannot create VLANS. vNets are created using a technique called overlay network. Overlay Network is built on top of other networks and it allows creating multiple networks (with conflicting address space) on top of same underlying shared network. Its done using technology similar to hyper-v network Virtualization (some say overlays are different than virtualization) using NVGRE where each customer’s network ID is added to each frame (not packet because packet is layer 3 concept and we need isolation at layer 2). I think if I go any further, it will dilute the topic. But the key thing is that you don’t get dedicated network on Azure. Its a shared space and data from multiple tenants flow on same infrastructure.

Layer 4:
This is the layer that we get to see and work as cloud users. At this layer we get protocols like TCP, UDP and ICMP are implemented on top of IPv4. There are many protocols that can be used by applications on top of IP layer. For each protocol, IP header’s protocol field has a number mentioned. You can see all common protocol numbers here.

Azure networks support only TCP, UDP and ICMP protocols and you need to keep this in mind before planning for a solution to be deployed on Azure Networks. Your solution may sometimes have the need to use other protocols than TCP, UDP and ICMP. Most of the protocols that software applications use are implemented on top of these. For example, http is implemented on top of TCP.

There are some protocols may run but not supported. The term supported means, if anything goes wrong, you can’t call Microsoft AND updates that Microsoft deploys on Azure “may” break your existing scenarios. Basically, you are on your own even though some protocols may work technically.

Even though TCP, UDP and ICMP are supported, the protocols that are implemented on top of these may not be “supported”… though technically possible. An example will be SNMP. SNMP uses UDP but so it gives an impression that SNMP should be supported. The reality is, even though technically you can use SNMP but it will NOT be “supported” by Microsoft because Microsoft gives SNMP as part of Windows OS and this feature of Windows OS is not supported yet. So its more of OS feature supportability rather than technical supportability. If you are planning to use any product on Azure you must do following:

(1) If you plant to build your own product using a specific protocol “directly”, check whether the protocol itself is supported or not

(2) If you plan to use a product/product feature (say SNMP using Windows Server) then you need to check whether the product feature is supported by vendor (Microsoft in case of Windows Server SNMP) on Azure or not

Some of the protocols are available for specific purposes only. As an example, IPSec is used to provide data security between “device-devices”, between “network-network” and between “device-network”. On Azure, IPSec can be used to provide secure connectivity between “network-network” (that too between two non-azure network-azure vNet and not used between two azure vNets) but is NOT supported for other use cases.

Key Takeaways:

  • Networks have a “language” that every entity/device should know how to speak. This means devices must be equipped with both software protocol (e.g., TCP/IP) as well as necessary hardware (Ethernet/Wifi).
  • Azure provides multiple virtual hardware concepts to join networks. The primary ones include Network Interface Cards (NIC) and Virtual Network Adapters (in form of VPN).
  • Azure networks supports only UDP, TCP and ICMP on top of IPv4. IPv6 is not supported yet. This is very important to keep in mind while designing solutions on Azure. Keep a checklist of protocols that your solution needs and see if it is supported or not as part of technical feasibility analysis.
  • Even if a protocol is supported, check if the vendor of the product that you wish to use on Azure supports it or not.
  • The actual underlying network on Azure is “shared” between tenants and isolation is provided using overlay networks. So, in reality, packets of multiple customers flow on same channel but they are still isolated and secure because users don’t get access to lower layers of networking stack. This is important from compliance perspective. Some organizations want a separate dedicated physical network which is NOT possible on Azure. In those scenarios, we go for hybrid approach to move only those components to Azure that can afford shared space.

I hope you enjoyed this small article that build foundation of networking concepts and how it is related with Azure from supportability perspective.

In the next article, I’ll talk about “when should we create networks”.

This series is also mirrored at The links in this article below will be updated as and when new articles are posted.

-Rahul Gangwar

Contact us for:

Azure Networks for Architects

Azure Networks for Architects is a series of articles where I’ll go over some of the aspects of designing networks on Microsoft Azure. This series will have multiple blog posts and in each article, I’ll go over one aspect about networks on Azure. The series is aimed to cover from very trivial and small concept to important ones.

Though the title of this series says “Architects” this will be helpful for multiple category of poeple including developers, IT professionals, project managers, technical leads, consultants… who want to understand much fine aspects about networking which is much beyond “How to” aspects. In the articles you’ll also find that there are very small things that we tend to overlook but they play important roles in overall design for any enterprise level deployment.

The concepts presented in this series come from a wide variety of sources including my experience while working with hundreds of customers in Microsoft as a Sr. Consultant, my takeaway while working with customers in ComTec as Solution Architect, my learning from some very knowledgeable people in the industry, my mistakes and my little power of visualization and analysis.

Why Networks only? I’m aiming to cover multiple aspects on cloud computing and I’m only “starting” with networks. In future you’ll see other components of designing cloud solutions like “storage”, “communication”, “security” and so on.

Why starting with networks? Networks for the backbone of any solution. The first step in deploying any solution involves creating its underlying infrastructure upon which entire solution is built. As you’ll see in articles of this series, Network design dictates many things about your solution like performance, availability, scalability, security, maintainability and cost. I’ve not used these terms to impress, as you’ll see, these are indeed affected by network design. I’m ignoring about a small set of solutions which are built on PaaS or SaaS and may not need network as such.

Solution vs Application/Software: You’d have seen me using the term solution very often. My title with ComTec also says “Solution Architect”. This is also a buzzword that many people use as it sounds fancy and kind of “deep” and “better” than other terms. Some thin k “Solution” is very large and complex software application. However, I’ve tried to take utmost care about terms that I use (I may still have have used some terms without much thought). The term “Solution” refers to the “Answer” to a “Problem” that we are trying to address. Some times answer to a problem may be a software application but not always. As we move beyond this networking series, you’ll see that the articles are more abstract (farther from “how to”) … more “strategic” than implementation oriented. Even a decision to not use a software could be a solution to problem.

This series is also mirrored at The links in this article below will be updated as and when new articles are posted.

List of Series Articles:

  1. What are Networks
  2. Designing Networks – Part 1 – Performance/Latency

Stay Tuned! Subscribe

Rahul Gangwar