How to master Azure Firewall, Private Endpoints and DNS

In Part 1, we have built the foundation for Azure virtual networks, subnets, NSGs, routing, and VNet peering. When you follow that guide you have a network and traffic flows, resources can talk to each other. Congratulations, you have created something that can be comprised…

In this part, which is part 2 is about Azure Firewall and private connectivity. It covers what you can do to stop your network from doing things that it should not do, and how you stop Azure PaaS services from being available from the internet when they have absolutely no business of being available from the outside. In this part, we cover Azure Firewall, Private Endpoints, Private Link and DNS Private Zones in Azure.

If Part 1 was about building roads then Part 2 is about deciding who is allowed to drive on them, where they can go and make sure petrol station is not visible from the motorway.

---

Why Network Security Groups (NSG) alone are not enough for protection

Before we dive into Azure Firewall it is worth mentioning about what Network Security Groups cannot do, because if you have only read Part 1 then you might be thinking “I have my network protected with NSG’s because I have placed them on my subnet, I am fine… well, you are not! You have something, that is better than nothing, which is a different thing.

NSG’s work at Layer 4, they understand IP addresses and port numbers but they do not understand what is inside a package. An NSG rule that is configured on TCP on port 443 will allow any HTTPS traffic, no matter if it’s legitimate or not. It is not capable of telling the difference between a developer pulling a Docker image from a trusted registry and the same developer that accidentally pulling a malicious one. Yes, both are TCP and both are port 443 and both get through.

Also, NSG’s have no idea of fully qualified domain names, you cannot create a NSG rule where you can define “allow traffic to *.microsoft.com” as you can only allow specific IP ranges. And this is a problem as Microsoft IP ranges change regularly, there is no way you will keep up. You will either allow to much or block something important.

Don’t get me wrong, NSG’s are essential, keep them, layer them and use them and especially with Azure Firewall but they are the internal walls not the security system.

How a Azure Firewall works as a managed layer 7 protection

An Azure Firewall is a full managed cloud native and stateful Layer 7 SaaS solution. This firewall lives ideally in your hub VNET and needs to be placed in its own dedicated subnet called ‘AzureFirewallSubnet’ and yes, that name is mandatory and cannot be changed. (Microsoft, please change that!) and all traffic from your spoke virtual networks routes through it via the UDR’s you have configured in Part 1.

The “Managed” part matters allot as Microsoft makes sure the firewall is patched, availability and scaling. The best part is, you don’t have to provision VM’s, manage OS updates or worry about whether your firewall comes back-up after updates (Palo Alto, are you reading??? ) No matter which SKU you take whether its Standard or Premium an Azure Firewall is always redundant and available. You write the policies and Azure handles the rest. This is an important difference from running a Palo Alto or Fortinet NVA yourself, where “managed” means “managed by you at midnight when the license expires”

Does that mean Azure is all rainbows and sunshine? Nope, As you cant just “back-up” Azure Firewall and yes you can manage the firewall through the Azure portal, is it smart? Not really… My advice is, when using Azure Firewall only deploy and manage it through IaC as the code is your back-up which contains all the policies. And managing rules through the portal is… a nightmare!

Azure Firewall SKUs: Standard vs Premium

There are two SKUs and the choice matters:

Feature	Standard	Premium
FQDN-based application rules	Yes	Yes
Network rules (IP/port)	Yes	Yes
Threat intelligence filtering	Yes	Yes
DNS proxy	Yes	Yes
TLS inspection (HTTPS decryption)	No	Yes
IDPS (Intrusion Detection & Prevention)	No	Yes
URL filtering (full path, not just FQDN)	No	Yes
Web categories	No	Yes

For most organisations the Standard is the right starting point and Premium is for environments where you need to inspect encrypted traffic, this is something that entirely depends on the environment and requirements.

Keep in mind, an Azure Firewall is by no means cheap… A standard runs roughly at €1.20/hour for the deployment itself, plus data processing charges. Premium costs more. In small environments this is a huge cost and when you add things like Policy Analytics if you want some firewall logging trough a GUI instead of running queries then you pay another 160-200 euro’s a month or so and when you look at DDoS protection it gets crazy fast… However for an environment that has allot of spoke environments with lots of subnets it is justified. A firewall from another brand ain’t cheap to.

The different Azure firewall rule types

The firewall processes the three rule types in a specific order and that is;

1. DNAT Rules (Destination Network Address Translation)

DNAT rules are needed to translate inbound traffic which has a destination on a public IP address that is assigned on the firewall to a private IP somewhere in your network. This is a way of exposing something internally without giving it a public IP directly. For example; Traffic arriving on the firewall public IP on port 3389 to an internal jump server at 10.1.4.5:3389

Keep in mind that Azure firewall has a big limitation (at least, that’s my opinion) and thats it cannot allow a range of ports with DNAT. And this is a huge fail because lets say you have a range of ports that you need to allow, the only way to do this with an Azure Firewall is enter one firewall rule per port, crazy right?

2. Network Rules

Network rules are rules that control traffic based on IP, port and protocol which does the same thing as a NSG rule. but central managed on the firewall. Use these network rules for non-HTTP traffic where FQADN resolution is not relevant. For example; SQL connections between spokes, SMTP relay etc.

There is a reason that I said earlier that my advice is to use NSG’s when you use an Azure Firewall… and it’s because of the network rules. Lets say you have a hub and spoke azure environment and the spokes contains multiple subscriptions which can be different project, customers etc and each subscription has its own VNET and they are all connected to VNET Hub. On a Monday morning at 09:00 AM you get a call to add a network rule to allow traffic from 10.1.0.0/24 on port 443 to the internet (yes I know if its browser traffic it needs to be a application rule but this is just an example as this issue also applies to application rules…). The rule you create is 10.1.0.0/24 on 443 and destination is not internet, because you cannot choose that but it’s ANY. This means you are not allowing it do just the internet… but also opening it on every virtual network in your spoke, so now you just opened port 443 from 10.1.0.0/24 to every network in your peered networks… and thats where NSG’s come in, if you place NSG’s on your subnets then you can place rules that you only allow traffic from specific networks and this means this traffic gets denied at NSG level.

If you didn’t use NSG’s traffic would be allowed… And this also applies to Application Rules.

3. Application Rules

Applications rules are used to allow or deny traffic based on fully qualified domain names rather than IP addresses. You could write a rule that allows your application subnet to reach *.microsoft.com and nothing else. This way, it doesn’t matter if Microsoft changes their IP ranges, your rule still works as its added on DNS name instead of IP.

Rule Collection: allow-windows-update
Priority: 200
Action: Allow

Rule: windows-update-fqdns
Source: 10.2.0.0/16  (production spoke)
Protocol: HTTPS:443, HTTP:80
Target FQDNs:
  *.windowsupdate.microsoft.com
  *.update.microsoft.com
  *.windowsupdate.com
  *.download.windowsupdate.com

Azure firewall also supports FQDN tags, these are pre-built groups of FQDN’s for common Microsoft services, like Windows Update, Azure Backup or Entra ID which makes it easier to allow or deny rules to these services. Instead of maintaining your own list oft FQDN’s , use these tags and let Microsoft provide an up-to-date tag. My advice, use whenever it can, they are one the most underrated features in Azure Firewall.

The right way to manage rules with firewall policy

Firewall rules in this firewall are managed through firewall policy, this is a standone resource that you attach to one or more firewall instances. Important to know is that each firewall can only support one firewall base policy, but you can assign it to multiple firewalls and a base policy can support multiple child policies. It support hierarchy and this means that a base policy placed at the management group or on susbcription level containing organisation wide rules, which child policies per environment or team that inherit in the base and can then ad their own.

Policy Level	Contains	Managed By
Base Policy	DNS settings, threat intel, global allow/deny rules	Platform / networking team
Child Policy (Production)	Production-specific application and network rules	Platform team
Child Policy (Development)	More permissive rules for development environments	Dev team (within guardrails)

Without policy hierarchy, you end up copy-pasting the same base rules into every environment. Someone updates one copy and not the others. You find this out during an incident. Use the hierarchy.

Azure Firewall vs NSGs: Use both, understand the difference

I already talked a bit about it but this is something that comes up often; if I have an Azure firewall, do I still need to use NSG’s? Yes! they serve different purposes at different layers and also fixes an ‘issue’ with the azure firewall.

	NSG	Azure Firewall
OSI Layer	Layer 4	Layer 4–7
Scope	Per subnet or NIC	Centralised hub
FQDN rules	No	Yes
TLS inspection	No	Yes (Premium)
Threat intelligence	No	Yes
Cost	Free	Paid
Best used for	East-west micro-segmentation	North-south and spoke-to-spoke inspection

There is also an important thing that I haven’t mentioned yet but there is also a big difference between the two how it handles traffic and what it can see. NSG’s handle lateral movement between subnets with a spoke. So lets say you have two subnets within a virtual network then a NSG can handle that traffic and can also see that traffic while Azure firewall handles traffic leaving spokes toward the itnernet or toward other spokes, so when traffic leaves a VNET! this is so important to understand because this will make troubleshooting so much easier!

In other words, multiple independent layers, each doing what it doest best.

A common mistake that I see is that people removing NSG’s from subnets because ” we already have a firewall, we dont need them”. If Azure Firewall is msconfigured, or traffic somehow bypasses it or you allow network/application traffic to ‘any’ then your NSG’s are your last line of defence. Never remove them.

What to do with DNS proxy? Enable it, always!

When you have an Azure Firewall then there is a DNS proxy feature includes, that when enabled, makes the firewall act as the DNS resolver for all VM’s in your spoke VNET’s. You point your VNET’s DNS setting to the firewall private IP and all DNS traffic queries flow right through it and this matters for two reasons. The first one is that FQDN based application rules require the firewall to resolve the domain name itself, without DNS proxy the FQDN rules cannot work reliably. Second reason is that the firewall can log all DNS queries which gives you full visibility into what your resources are trying to reach before they reach it.

It takes just two minutes to activate it and this ensures that FQDN rules actually works.

Private Endpoints and Private Link: Taking PaaS services off the public Internet

This is something where I see allot of organisations make mistakes with, and to be more precise, not using them… they go to the Azure portal and choose a service, click click next, finish and it works! And I see this way to much, I have seen complete data solutions connected over the internet, and the reason: it just works… if something just works, doesn’t mean its secure or smart way to do it, right? This should any security conscious engineer uncomfortable.

For internal workloads handling sensitive data, that is not an acceptable posture. Private Endpoints solve it.

What a Private Endpoint actually is

A Private Endpoint is a network interface deployed into a subnet in your virtual network with a private IP from that subnet’s range. That interface is connected via Azure’s Private Link platform which is directly connected to a specific PaaS service instance. From that point on, traffic from your VNet to that service travels entirely over Microsoft’s private backbone. It never touches the public internet.

To make it more concrete: When you create a Private Endpoint for your storage account in snet-data(10.1.3.0/24). Azure creates a private endpoint with say IP address of 10.1.3.10 and maps it to that storage account. Your VMs now can reach the storage account via 10.1.3.10. The traffic stays entirely within your private network. After this, you can, and in most secure environment you should always disable the storage account’s public endpoint entirely.

Which Services support Private Endpoints

The list is long and grows regularly. The ones you will encounter in almost every architecture:

• Azure Storage (Blob, File, Queue, Table, Data Lake)
• Azure SQL Database and SQL Managed Instance
• Azure Key Vault
• Azure Service Bus and Event Hubs
• Azure Cosmos DB
• Azure Container Registry
• Azure Kubernetes Service (API server)
• Azure App Service and Function Apps
• Azure Monitor (Log Analytics, Application Insights)

For the complete and current list, see Microsoft’s Private Link resource type documentation.

Private Link service: Exposing your own services privately

Private Link is the underlying platform technology that uses Private Endpoints, and it has a second use case that is often overlooked. Private Link Service lets you expose your own application with an internal API running behind an Azure Load Balancer connected to another organisation’s VNet, without peering, without any shared network infrastructure, and without exposing it publicly.

The consumer creates a Private Endpoint in their VNet and the traffic flows privately over Microsoft’s backbone. Neither party sees the other’s network. This is extremely useful in multi-tenant SaaS architectures and in scenarios where you need to share services across organisational boundaries without the complexity of full network connectivity.

NSGs and Private Endpoint subnets

Private Endpoints do not respect NSG rules by default and therefore network policies must be explicitly enabled on the subnet itself if you want NSG’s be apply to apply This changed in 2023 and is now fully supported, but it is not the default. If you deploy Private Endpoints into a subnet that has NSGs and wonder why the rules are not being evaluated, this is why.

# Enable NSG support for Private Endpoints on a subnet
az network vnet subnet update \
  --name snet-privateendpoints \
  --resource-group rg-network \
  --vnet-name vnet-prod \
  --private-endpoint-network-policies Enabled

Subnet recommendation: Deploy Private Endpoints into a dedicated subnet (e.g. snet-privateendpoints) rather than mixing them with compute resources. This makes NSG management cleaner, keeps Private Endpoint IPs predictable, and makes your architecture easier to document and audit.

Azure DNS Private Zones: Making names resolve correctly

You have deployed a Private Endpoint for your storage account, with a private IP of 10.1.3.10 mapped to it. Next, connecting from a VM in your virtual network using the normal hostname seems like the obvious step: mystorageaccount.blob.core.windows.net. It resolves to a public IP and the traffic goes to the public endpoint, bypassing your Private Endpoint entirely.

This is the DNS problem. And it catches almost everyone out the first time.

Why the DNS problem exists

When you create a Private Endpoint at that point Azure does not change how the hostname resolves globally. Publicly, it still resolves to the service’s public IP. Your application uses the standard hostname as it should and DNS sends it to the public endpoint.

What you need is split DNS: the same hostname resolving to different answers depending on who is asking. Inside your VNet, mystorageaccount.blob.core.windows.netshould resolve to 10.1.3.10. Everywhere else, it resolves to the public IP as normal. Using Azure DNS Private Zones is how you achieve this.

How Azure DNS Private Zones work

An Azure DNS Private Zone is a private DNS zone linked to one or more virtual networks. Resources in those VNets use the private zone for name resolution. Resources outside those VNets do not see the zone at all. For Private Endpoints, each Azure service has a predefined private DNS zone name:

Service	Private DNS Zone Name
Azure Blob Storage	privatelink.blob.core.windows.net
Azure File Storage	privatelink.file.core.windows.net
Azure SQL Database	privatelink.database.windows.net
Azure Key Vault	privatelink.vaultcore.azure.net
Azure Service Bus	privatelink.servicebus.windows.net
Azure Container Registry	privatelink.azurecr.io
Azure Cosmos DB (SQL)	privatelink.documents.azure.com
Azure Monitor / Log Analytics	privatelink.ods.opinsights.azure.com

For the complete list, see Microsoft’s Private Endpoint DNS configuration documentation.

The Setup: Step by Step

1. Create the Private Endpoint in the appropriate subnet.
2. Create (or reuse) the Azure DNS Private Zone for that service type — e.g. privatelink.blob.core.windows.net.
3. Link the Private Zone to your VNet (and any peered VNets that need to resolve it).
4. Ensure the Private Endpoint DNS integration is configured to write an A record into the zone automatically.
5. Verify: from a VM in the linked VNet, run nslookup mystorageaccount.blob.core.windows.net. It should return the private IP, not the public one.

One zone per service type, not per resource. You need one privatelink.blob.core.windows.net zone for all your storage accounts, not one zone per storage account. Each Private Endpoint adds its own A record to the shared zone. Creating a separate zone per resource is a very common mistake that leads to resolution conflicts and a lot of confused troubleshooting.

DNS Private Zones in a Hub-and-Spoke Architecture

In a hub-and-spoke topology, centralise your Private DNS Zones in the hub VNet and link them to all spoke VNets. Combined with Azure Firewall’s DNS proxy, the resolution path becomes clean: VM in spoke → Firewall DNS proxy in hub → Azure DNS → Private Zone record → private IP.

This requires that all of the following are correctly configured:

• 1) The Private DNS Zone is linked to the hub VNet
• 2) Azure Firewall DNS proxy is enabled and VNet DNS points to the firewall’s private IP
• 3) The firewall forwards to Azure DNS (168.63.129.16)
• 4) Private Endpoints are in a subnet with network policies enabled

Get any one of these wrong and DNS resolution fails silently, your application reaches the public endpoint instead of the private one and you spend an afternoon in Network Watcher wondering why. The nslookup verification step above is not optional. Run it every time.

On-Premises DNS and Private Endpoints

If on-premises systems need to reach Azure PaaS services via Private Endpoints, on-premises DNS servers cannot query Azure DNS Private Zones directly. The solution is conditional forwarders: configure your on-premises DNS to forward queries for privatelink.* zones to Azure DNS via your VPN or ExpressRoute connection.

The recommended approach is Azure DNS Private Resolver, a managed service that provides inbound and outbound DNS endpoints inside your VNet, enabling on-premises systems to query private zones without needing custom DNS VMs. This is not a cheap solution, but it is a set and forget one. You can also set up a small linux VM and configure BIND9 to use it as a private resolver, this is atleast 10 times cheaper then the Azure service in operating cost but then you have a VM to maintain…This is covered in depth in Part 4 alongside hybrid connectivity.

---

Putting it together: A fully secured Hub-and-Spoke Architecture

With Azure Firewall, Private Endpoints, and DNS Private Zones in place, here is what the complete picture looks like:

Component	Location	Purpose
Azure Firewall	Hub VNet — AzureFirewallSubnet	Inspect and control all hub-spoke and spoke-to-spoke traffic
DNS Private Zones	Hub VNet (linked to all spokes)	Resolve PaaS service names to private IPs
Private Endpoints	snet-privateendpoints in each spoke	Bring PaaS services onto the private network
NSGs	Every subnet in every spoke	Micro-segmentation within spokes
UDRs	Every spoke subnet route table	Force all traffic through the hub firewall
Firewall Policy	Management subscription	Centralised rule management with base and child hierarchy

Traffic flow for a VM in a production spoke reaching Azure Storage:

1. VM queries DNS for mystorageaccount.blob.core.windows.net
2. Query goes to Azure Firewall (DNS proxy), which forwards to Azure DNS
3. Azure DNS returns the CNAME mystorageaccount.privatelink.blob.core.windows.net
4. Private Zone resolves that to 10.1.3.10 (the Private Endpoint IP)
5. VM connects to 10.1.3.10 and traffic stays entirely within the private network
6. NSG on snet-privateendpoints validates the connection is from an allowed source

No traffic touched the public internet. Additionally, no IP addresses were hardcoded anywhere in the ruleset. Furthermore, when Microsoft changed a service IP behind the scenes, not a single firewall rule needed updating. That is the architecture working as intended.

Summary: What you should take away from part 2

Azure Firewall

• Managed, stateful Layer 7 firewall. Lives in the hub, all spoke traffic routes through it via UDRs.
• Standard for most organisations. Premium for TLS inspection and IDPS.
• Three rule types evaluated in order: DNAT, Network, Application (FQDN-based).
• Use Firewall Policy with base and child hierarchy, do not manage rules directly on the firewall instance.
• Enable DNS proxy and point VNet DNS to the firewall. FQDN rules do not work reliably without it.
• NSGs and Azure Firewall are complementary. Use both. Never remove NSGs because you have a firewall.

Private Endpoints and Private Link

• Private Endpoints bring PaaS services onto your VNet with a private IP. Traffic stays off the public internet.
• Disable the public endpoint on PaaS services after creating a Private Endpoint , do not leave both active in secure environments.
• Enable network policies on Private Endpoint subnets if you want NSGs to apply.
• Use a dedicated snet-privateendpoints subnet. Keep Private Endpoints separate from compute.
• Private Link Service lets you expose your own services privately, useful for cross-organisation connectivity without network peering.

Azure DNS Private Zones

• Required for Private Endpoints to work correctly. Without them, traffic silently goes to the public endpoint.
• One zone per service type, not one per resource.
• Centralise zones in the hub VNet and link to all spokes.
• Always verify with nslookup after setup, silent failures are common.
• For hybrid (on-premises) access, use Azure DNS Private Resolver, covered in Part 4.

---

In Part 3, we cover load balancing — all four Azure options (Azure Load Balancer, Application Gateway, Azure Front Door, and Traffic Manager), when to use each, and how they fit into the architectures built across Part 1 and Part 2.

---

This article is part of the Azure Networking series on larsschouwenaars.com. Start with Part 1: VNets, Subnets, NSGs and Routing, or browse all networking articles.