Azure Firewall enforces three distinct rule collections processed in a strict priority order. Understanding all three is essential to designing a secure hub and spoke topology.

The three rule types are processed top to bottom — DNAT first, then network, then application. A match at any layer stops processing. If nothing matches, traffic is implicitly denied.

Rule Type 1 — DNAT Rules

Destination Network Address Translation rewrites the destination IP (and optionally port) of inbound traffic hitting the firewall’s public IP, redirecting it to a private backend inside a spoke VNet.

What it does

Internet client → Firewall public IP (52.x.x.x:443)
                        ↓  DNAT rule fires
                  Rewrites destination to 10.1.4.5:443
                        ↓
                  Backend VM in production spoke

Example DNAT rules

Key rules about DNAT

• DNAT rules implicitly create a matching network rule to allow the translated traffic through — you don’t need a separate network rule for the return path.
• DNAT only applies to inbound traffic — traffic arriving at the firewall’s public IP from outside.
• You cannot DNAT to a broadcast or multicast address.
• After translation, the packet is treated as if it came from the firewall’s private IP — so your backend VMs see the firewall, not the original client. Preserve source IP with SNAT if needed.

Rule Type 2 — Network Rules

Network rules are Layer 3/4 filters — they match on source IP, destination IP, port, and protocol. No payload inspection. This is the right tool for non-HTTP traffic: SQL, RDP, SMB, DNS, NTP, custom protocols.

What it does

Spoke VM (10.1.2.5) → SQL Server (10.3.4.10:1433)
        ↓
Network rule: allow src=10.1.0.0/16 dest=10.3.4.10 port=1433 proto=TCP
        ↓
Traffic passes — no application-layer inspection

Example network rules

Network rule features

IP Groups — reusable objects containing lists of IPs and CIDRs, so you don’t repeat 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 in every rule:

IPGroup: "all-spokes" = [10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, 10.4.0.0/16]

FQDN in network rules — you can use FQDNs as destinations in network rules (e.g. *.windows.update.com) but only for TCP/UDP. The firewall resolves the FQDN using its DNS settings and matches on the resolved IP.

Service Tags — Microsoft-managed groups of IP ranges for Azure services:

Source: 10.0.0.0/8  →  Destination: AzureMonitor  →  Port: 443  →  Allow

Common tags: AzureCloud, AzureMonitor, Storage, Sql, WindowsUpdate, MicrosoftDefenderForEndpoint

Rule Type 3 — Application Rules

Application rules operate at Layer 7 — they can inspect the HTTP/HTTPS host header and URL path, enforce FQDN allow-lists, apply web category filtering, and (with Premium SKU) perform full TLS inspection.

What it does

Spoke VM → HTTPS request to api.github.com
        ↓
Application rule: allow src=10.1.0.0/16 target=*.github.com proto=Https
        ↓
Firewall checks SNI / Host header — matches rule
        ↓
Traffic passes (or inspected if TLS inspection enabled)

Example application rules

FQDN Tags — Microsoft-managed bundles

Instead of listing dozens of Microsoft service URLs manually, use built-in FQDN tags:

Azure Firewall SKUs

TLS inspection (Premium only) decrypts HTTPS traffic, inspects the payload with IDPS signatures, then re-encrypts it. Requires deploying a CA certificate chain trusted by all spoke VMs — typically distributed via Group Policy or Intune.

Firewall Policy vs Classic Rules

Modern Azure Firewall uses Firewall Policy — an ARM resource that holds all rule collections and can be shared across multiple firewall instances:

Firewall Policy (parent — global rules)
        ↓  inheritance
Firewall Policy (child — environment-specific rules)
        ↓  applied to
Azure Firewall instance (hub VNet)

This lets you enforce baseline rules (e.g. deny dev→prod) at the parent policy level across all environments, while child policies add environment-specific rules. Child policies cannot override parent deny rules.

Rule Processing Priority — the Full Picture

Priority 100 (lowest number = highest priority)
    DNAT collection A   → rules evaluated top to bottom
    DNAT collection B
Priority 200
    Network collection A  → IP/port rules
    Network collection B
Priority 300
    Application collection A  → FQDN / URL rules
    Application collection B
Priority 65000 (built-in)
    Allow Azure infrastructure FQDNs (IMDS, DNS, etc.)
Priority 65500 (built-in)
    Implicit deny all

Rule collections within each type are evaluated by priority number — lowest number wins. Within a collection, rules are evaluated top to bottom and the first match wins.

Here’s the Azure Hub and Spoke network architecture — the foundational enterprise network pattern on Azure. I’ll show it in two diagrams: the overall topology first, then the hub internals in detail.

The topology shows the hub as the central control point, with all spoke VNets peered to it. Now here’s a closer look at what lives inside the hub and how traffic flows through it.

Azure Hub and Spoke — Key Design Principles

Why Hub and Spoke?

Hub and spoke is the recommended enterprise network topology for Azure. Instead of each team or workload managing its own connectivity and security, all shared services live in one central hub VNet, and workloads live in isolated spoke VNets peered to it.

Every spoke talks to the world THROUGH the hub — never directly.

The Hub VNet — what lives inside

The hub is the security and connectivity control plane. It contains no workloads — only shared infrastructure:

• VPN Gateway / ExpressRoute Gateway — the on-premises bridge, placed in a dedicated GatewaySubnet. All hybrid traffic enters and exits here.
• Azure Firewall — placed in AzureFirewallSubnet, it inspects all east-west (spoke-to-spoke) and north-south (internet/on-prem) traffic. Every spoke uses a User Defined Route (UDR) pointing 0.0.0.0/0 to the firewall’s private IP.
• Azure Bastion — placed in AzureBastionSubnet, it provides browser-based RDP/SSH to any VM in any peered spoke without requiring public IPs on the VMs.
• Route Server — exchanges BGP routes with Network Virtual Appliances (NVAs) so dynamic routing updates propagate automatically across all spokes.
• DNS Private Resolver — centralises DNS resolution for all private DNS zones, so every spoke resolves *.privatelink.azure.com correctly through the hub.
• DDoS Protection Standard — applied at the subscription level, protects all public IPs across hub and spokes from volumetric attacks.

The Spoke VNets — what lives inside

Each spoke is an isolated workload boundary:

Spokes cannot talk to each other directly — traffic must traverse the hub firewall, giving you full inspection and control of lateral movement.

Traffic flow rules

All routing is forced through the hub firewall via UDRs applied to every spoke subnet:

Spoke VM → UDR (0.0.0.0/0 → Firewall IP)
              ↓
        Azure Firewall (inspect, allow/deny)
              ↓
        Destination (internet / on-prem / other spoke)

This means even spoke-to-spoke traffic — for example, production VM calling a shared services VM — travels hub → firewall → hub → destination, giving you a full audit trail.

Address space planning

Non-overlapping CIDRs are mandatory — VNet peering fails if address spaces overlap:

Hub VNet:              10.0.0.0/16
  GatewaySubnet:       10.0.0.0/27   (min /27 for gateway)
  AzureFirewallSubnet: 10.0.1.0/26   (min /26)
  AzureBastionSubnet:  10.0.2.0/26   (min /26)
  RouteServerSubnet:   10.0.3.0/27   (min /27)
Spoke 1 (prod):        10.1.0.0/16
Spoke 2 (dev):         10.2.0.0/16
Spoke 3 (shared svc):  10.3.0.0/16
Spoke 4 (DMZ):         10.4.0.0/16

When to use Azure Virtual WAN instead

Hub and spoke with manual VNet peering works well up to ~10 spokes. Beyond that, consider Azure Virtual WAN — a Microsoft-managed hub that automatically handles routing, peering, and gateway scaling across dozens of spokes and multiple regions, at the cost of less customisation flexibility.

The Hub and Spoke—the gold standard of enterprise networking in Azure. It’s the architectural equivalent of a major airport hub (the Hub) connecting to various smaller regional airports (the Spokes).

In this setup, you centralize shared services to save money and improve security, while letting individual workloads live in their own isolated Spokes.

The Architecture Breakdown

1. How Private Endpoints fit into Hub & Spoke

This is where most engineers get a headache. You have two main choices for where to put your Private Endpoints:

Option A: The “Distributed” Model (Endpoints in Spokes)

You put the Private Endpoint directly in the same VNet as the VM/App that needs it.

• Pros: Easier to set up initially; traffic stays within the Spoke.
• Cons: Harder to manage at scale if you have 50 Spokes.

Option B: The “Centralized” Model (Endpoints in the Hub)

You put all Private Endpoints in a dedicated “Shared Services” subnet in the Hub.

• Pros: One place to manage all private IPs; better for shared databases.
• Cons: Requires “Transitive Routing”—traffic must go from Spoke A -> Hub -> Private Endpoint.

2. The DNS Challenge in Hub & Spoke

If your Private DNS Zone lives in the Hub, but your VM lives in the Spoke, the Spoke VM won’t be able to resolve the name unless you do one of these:

1. Link the DNS Zone to every Spoke: You must create a Virtual Network Link between the Hub’s Private DNS Zone and every Spoke VNet.
2. Centralized DNS Resolver: Use the Azure DNS Private Resolver in the Hub. Spokes point to the Hub’s IP for DNS, and the Hub handles the lookup.

3. Troubleshooting Hub & Spoke with Network Watcher

When a VM in a Spoke can’t talk to a Database in the Hub (or another Spoke), here is your checklist:

A. The “Gatekeeper” (VNet Peering)

Check the Peering status. If it doesn’t say Connected, nothing else matters.

• Crucial Setting: For Spokes to use a VPN/ExpressRoute in the Hub, you must enable “Use Remote Gateways” on the Spoke and “Allow Gateway Transit” on the Hub.

B. The “Traffic Cop” (Next Hop)

In a Hub and Spoke, you often want traffic to go through an Azure Firewall in the Hub.

• Use Network Watcher Next Hop: If the Next Hop is “Internet” instead of the “Virtual Appliance” (Firewall IP), your User-Defined Route (UDR) is missing or wrong.

C. The “Blind Spot” (Non-Transitivity)

VNet Peering is NOT transitive.

• If Spoke A is peered to the Hub, and Spoke B is peered to the Hub, Spoke A cannot talk to Spoke B through the Hub automatically.
• The Fix: You must use an NVA (Network Virtual Appliance) or Azure Firewall in the Hub to route that traffic, or peer Spoke A and B directly.

Summary Checklist for “Defense in Depth” Setup

• [ ] Hub VNet: Contains Firewall and VPN/ER Gateway.
• [ ] Spoke VNets: Peer to Hub with “Use Remote Gateways” enabled.
• [ ] DNS: Private DNS Zones live in the Hub and are linked to all Spokes.
• [ ] Routing: UDRs on Spoke subnets force 0.0.0.0/0 traffic to the Hub Firewall.
• [ ] Monitoring: Network Watcher is enabled in both the Hub and Spoke regions.

You can route Spoke-to-Spoke traffic through a central Firewall, or your Spokes mostly be isolated from one another.

First things first: If you’re looking for “Azure Active Directory” in the Azure portal today, you’ll find it under its new name: Microsoft Entra ID.

Microsoft rebranded the service to align it with their broader “Entra” identity and network access family. While the name has changed, the core functionality—managing users, groups, and permissions for the cloud—remains the same.

1. What is Microsoft Entra ID?

It is a Cloud-native Identity and Access Management (IAM) service. Unlike traditional Active Directory (which runs on local servers), Entra ID is designed for the internet.

• It’s not just for Azure: It provides Single Sign-On (SSO) to thousands of apps like Salesforce, Zoom, and Google Workspace, not just Microsoft services.
• The “Zero Trust” Engine: It is the primary tool used to verify every access request based on user identity, location, device health, and service risk.

2. Core Pillars of Identity

To master Entra ID, you need to understand these four concepts:

3. Azure AD (Entra ID) vs. Windows Server AD

This is the most common point of confusion. They are different tools for different jobs:

• Windows Server AD: Uses protocols like Kerberos and LDAP. It’s built for managing physical desks, local printers, and file shares inside a building.
• Microsoft Entra ID: Uses modern web protocols like OAuth 2.0, SAML, and OpenID Connect. It’s built for web apps and remote work.

The Hybrid Reality: Most companies use Microsoft Entra Connect to sync their on-premises users up to the cloud. This way, a user has one password for their laptop and their email.

4. Key 2026 Features & Updates

As of now in 2026, several high-impact features have become standard:

• Phish-Resistant MFA: Entra ID now heavily pushes FIDO2 security keys and certificate-based authentication to combat modern “MFA Fatigue” attacks.
• Entra ID Protection: Uses AI to detect “Risky Sign-ins.” If a user logs in from New York and then 5 minutes later from London, the system automatically blocks the account (Impossible Travel).
• External ID: A unified way to manage “Guests”—like contractors or customers—without cluttering your main employee directory.

Troubleshooting Tip: The “Sign-in Logs”

If a user can’t log in, don’t guess. Go to Microsoft Entra ID > Monitoring > Sign-in logs.

It will give you a specific failure reason, such as:

• MFA requirement not met.
• Blocked by a specific Conditional Access policy.
• Account locked due to too many bad passwords.

Where you have a Cloud-only presence (like new SaaS apps or a startup) and a Hybrid presence (syncing from a local office)—your identity strategy becomes the bridge that holds everything together.

As of 2026, Microsoft Entra ID handles these two worlds using different synchronization engines.

1. The Hybrid Bridge: Connect vs. Cloud Sync

If you have an existing on-premises Active Directory (AD), you need to get those users into the cloud. You have two primary tools to do this:

2026 Recommendation: If you don’t need “Device Writeback” or complex Exchange Hybrid features, move to Cloud Sync. It is easier to maintain and doesn’t require you to manage a heavy local database.

2. The Cloud-Only Side: “Entra Joined”

For your new cloud-native resources (like a remote employee’s laptop or a new Azure VM), you should skip the local domain entirely.

• Entra ID Joined: The device is managed entirely in the cloud. There is no local Domain Controller involved.
• Benefits: Users can log in from anywhere without a VPN, and you manage the device via Microsoft Intune instead of old-school Group Policy (GPOs).

3. Managing “Both” (The Operational View)

When you are in a hybrid state, you are managing identities in two places at once. This requires a strict “Defense in Depth” approach to identity security.

A. The “UPN” Golden Rule

Your User Principal Name (e.g., john@company.com) must match exactly between your local AD and Entra ID. If they don’t match, your users will experience constant login prompts and “Account not found” errors.

B. Conditional Access (The Brain)

This is where you manage “Both” types of users. You can create a policy that says:

• If the user is Synced (Hybrid) and on a corporate device, allow access.
• If the user is Cloud-only and on an unknown device, require Phish-resistant MFA (FIDO2).

4. Troubleshooting “Both”

When something goes wrong in a hybrid/cloud environment, the culprit is usually the Sync Cycle.

• Scenario: You updated a user’s name in local AD, but it hasn’t changed in Azure.
  • Check: Open the Synchronization Service Manager on your local server. It will show you if the “Export” to the cloud failed.
  • Manual Trigger: Use PowerShell to force a sync if you’re in a hurry:Start-ADSyncSyncCycle -PolicyType Delta
• Scenario: A user is locked out of their cloud apps but can still log into their desk PC.
  • Check: Check the Entra Sign-in Logs. If it says “Authentication Failed,” but the password is correct, check if the Password Hash Sync (PHS) service is currently “Healthy” in the Entra Admin Center.

Summary Checklist for “Both”

• [ ] Standardize UPNs: Ensure local mail attributes match cloud logins.
• [ ] Enable SSPR: Set up Self-Service Password Reset with “Password Writeback” so cloud password changes update the local AD.
• [ ] Modernize Devices: Aim for Entra Join for new PCs, leaving Hybrid Join only for legacy servers that strictly require it.
• [ ] Monitor Health: Check the Hybrid Health Dashboard weekly to catch sync errors before users notice them.

Private Endpoints are the “final boss” of Azure networking troubleshooting. They are incredibly secure because they keep traffic off the public internet, but they introduce a layer of complexity—specifically around DNS resolution.

If your Private Endpoint isn’t working, 9 times out of 10, it’s a DNS issue.

1. The “DNS Trap” (Check this first!)

When you create a Private Endpoint for a service (like Azure SQL or Storage), the service still has a public FQDN (e.g., mydb.database.windows.net).

• The Problem: Your VM might be trying to connect to the Public IP instead of the Private IP of the endpoint.
• The Test: Run nslookup <your-resource-name>.database.windows.net from your client VM.
  • Fail: It returns a Public IP. Your VM is trying to go out to the internet.
  • Success: It returns a Private IP (e.g., 10.0.0.5).

The Fix: Ensure your Private DNS Zone is correctly linked to your Virtual Network and that the A-record for the resource exists.

2. Using Network Watcher for Private Endpoints

Once you’ve confirmed DNS is pointing to the right IP, use Network Watcher to see why the “handshake” is failing.

IP Flow Verify

Check if an NSG is blocking the traffic.

• Crucial Note: By default, Network Security Groups (NSGs) did not apply to Private Endpoints. However, Azure recently added a feature called “Network Policy for Private Endpoints.” * If this policy is Enabled on the subnet, your NSG could be blocking the traffic. Run IP Flow Verify to see if a “Deny” rule is stopping your VM from hitting the Private Endpoint’s IP.

Connection Troubleshoot

This is the most effective tool here because it tests the entire path.

• Setup: Set the Source as your VM and the Destination as the Private IP of the endpoint.
• What it reveals: It will tell you if the issue is a platform-level problem or a routing loop.

3. The “Hidden” Subnet Setting

A common “gotcha” when debugging Private Endpoints is the Subnet Private Endpoint Network Policy.

1. Go to your Virtual Network -> Subnets.
2. Click on the subnet where your Private Endpoint lives.
3. Look for “Private endpoint network policy”.
   • If you want to use NSGs to filter traffic to the Private Endpoint, this must be set to “Enabled”.
   • If it’s disabled, your NSGs are ignored for that endpoint, which can be a security hole (or a source of confusion during debugging).

4. Resource-Level Firewall

Even if the network is clear, the Target Resource (the SQL DB, the Key Vault, etc.) has its own internal “firewall” settings.

• The Debug Step: Go to the “Networking” blade of the resource itself (e.g., the Storage Account).
• The Check: Make sure “Public Network Access” is set to “Disabled” or “Enabled from selected virtual networks and IP addresses”, and ensure your Private Endpoint is listed as “Approved” in the Private Endpoint Connections tab.

Troubleshooting Checklist

Peer Tip: Don’t bother pinging a Private Endpoint. Most Azure PaaS services (like SQL or App Service) disable ICMP (ping) at the platform level. You can have a perfect connection and ping will still time out. Use Test-NetConnection -Port 443 (for HTTPS) or 1433 (for SQL) instead.

If are you seeing a “Connection Refused” error, or is the request simply timing out, that distinction usually tells you if the problem is the Firewall or the Routing.

When we talk about Private Endpoints, the “both” almost always refers to the two halves of the puzzle: DNS (the name) and Connectivity (the path). If one works but the other doesn’t, the connection fails.

1. The DNS Side (The “Who”)

This is where 90% of Private Endpoint issues live. You need your computer to look up mydb.database.windows.net and get a Private IP (like 10.0.0.5) instead of a Public IP.

How it works:

• The Private DNS Zone: Azure uses a special zone (e.g., privatelink.database.windows.net) to override the public internet record.
• Virtual Network Links: For your VM to “see” that private zone, the Private DNS Zone must be linked to the Virtual Network where the VM lives.
• The CNAME Magic: Azure uses a CNAME chain. It goes:mydb.database.windows.net -> mydb.privatelink.database.windows.net -> 10.0.0.5.

Troubleshooting the DNS “Half”:

• The Tool: Use nslookup or dig.
• The “Tell”: If you see a public IP or an error saying the name can’t be resolved, your VNet Link is missing or your DNS server (if using custom DNS) isn’t forwarding requests to the Azure WireServer IP (168.63.129.16).

2. The Connectivity Side (The “How”)

Even if you have the right IP, the “wires” (virtual or otherwise) must allow the traffic to flow.

The Key Hurdles:

• NSG Support (Network Policy): By default, Network Security Groups (NSGs) ignore Private Endpoints. If you want to block or allow traffic to a Private Endpoint using an NSG, you must Enable Private Endpoint Network Policy on the subnet.
• VNet Peering: If your VM is in VNet A and your Private Endpoint is in VNet B, you need VNet Peering set up. Furthermore, VNet A must also be linked to the Private DNS Zone in VNet B.
• The Resource Firewall: Some services (like Storage Accounts) have a “Firewalls and Virtual Networks” tab. You must ensure that “Public Network Access” is disabled or restricted, but the Private Endpoint Connection itself is marked as Approved.

How to Debug “Both” Simultaneously

If you are staring at a “Timed Out” error, follow this logic:

1. Test DNS: Run nslookup.
   • Public IP? Fix your DNS Private Zone/Linking.
   • Private IP? DNS is fine; move to step 2.
2. Test the Path: Run Test-NetConnection -ComputerName <FQDN> -Port 443.
   • TcpTestSucceeded : False? You have a routing or NSG issue.
   • TcpTestSucceeded : True? The network is perfect; the problem is likely your application’s credentials or configuration.

Comparison at a Glance

Peer Tip: When setting up Private Endpoints for a team, always use Azure Private DNS Zones integrated with the service. If you try to manage host files on individual VMs to “hack” the DNS, you will create a maintenance nightmare that will eventually break.

Let’s walk through a classic, “everything is on fire” scenario. This is the bread and butter of why Network Watcher exists.

The Scenario: “The Database is Down (But it’s Not)”

The Setup: You have a 3-tier application. Your Frontend Web VM is trying to connect to a Backend SQL VM on port 1433.

The Symptom: The web app is throwing “Connection Timed Out” errors. Your database admin swears the SQL server is up and running perfectly.

Here is how you use Network Watcher to find the culprit in 5 minutes.

Step 1: The “Bouncer” Check (IP Flow Verify)

First, you need to know if a firewall rule is blocking the traffic.

• Action: Run IP Flow Verify.
• Input: Source IP (Web VM), Destination IP (SQL VM), Port 1433, Protocol TCP.
• The Result: Network Watcher tells you: “Denied by Security Rule: DefaultRule_DenyAllInBound”.
• The Fix: You realize someone created a high-priority NSG rule that accidentally blocked all traffic to the backend subnet. You fix the rule.

Step 2: The “GPS” Check (Next Hop)

Traffic is now “Allowed” by the NSG, but the app still can’t connect. Now you check if the packets are actually being routed to the right place.

• Action: Run Next Hop.
• The Result: It shows the Next Hop is a Virtual Appliance (NVA) (like a Palo Alto or Fortigate firewall) instead of the Virtual Network.
• The Insight: You find an old User-Defined Route (UDR) that is forcing traffic through a firewall that isn’t configured to handle SQL traffic.
• The Fix: You update the Route Table to allow direct VNet-to-VNet communication for the SQL port.

Step 3: The “All-in-One” Diagnostic (Connection Troubleshoot)

The rules look good, the route looks good, but it’s still failing. You’re starting to sweat.

• Action: Run Connection Troubleshoot.
• The Result: It checks everything (DNS, Routing, NSG) and reports: “Status: Reachable” at the network level, but “Port unreachable” at the OS level.
• The Insight: This is the “Eureka” moment. The network is fine, but the application is rejecting the connection.
• The Fix: You log into the SQL VM and realize the Windows Firewall is turned on and blocking 1433, or the SQL service isn’t listening on the public IP.

Step 4: The “Deep Dive” (Packet Capture)

If Connection Troubleshoot had said “Network reachable” but you were seeing weird data corruption or intermittent drops, you’d go nuclear.

• Action: Start a Remote Packet Capture on both VMs.
• The Result: You download the .cap file and open it in Wireshark.
• The Insight: You see a “TCP Reset” packet being sent halfway through the handshake. This proves a middle-box (like a Load Balancer) is killing the connection due to an idle timeout.

Summary of the “Defense in Depth” Workflow

Peer Tip: Always start with IP Flow Verify. In 90% of Azure networking cases, the problem is a “Deny” rule in a Network Security Group that someone forgot existed.