Traffic Flow Through Azure Firewall via UDR

The UDR (User Defined Route) is the mechanism that forces all spoke traffic through Azure Firewall — overriding Azure’s default system routes which would otherwise send traffic directly between peered VNets, bypassing inspection entirely.

Why UDRs Are Necessary

Azure VNet peering by default creates direct routing between peered VNets — packets travel peer-to-peer without touching any intermediate device. This means without UDRs, a VM in Spoke 1 talking to a VM in Spoke 2 completely bypasses Azure Firewall:

Default behaviour (NO UDR):
  Spoke 1 VM (10.1.1.4) → Spoke 2 VM (10.2.1.4)
  System route: 10.2.0.0/16 → VNet peering (direct)
  Result: traffic bypasses firewall entirely 

With UDR applied to spoke subnet:
  Spoke 1 VM (10.1.1.4) → Spoke 2 VM (10.2.1.4)
  UDR overrides: 0.0.0.0/0 → 10.0.1.4 (Firewall private IP)
  Result: traffic hits firewall → inspected → forwarded 

The UDR wins because custom routes always override system routes — Azure’s route selection priority is custom UDR first, then BGP routes, then system routes.

Route Table Structure

A route table is an Azure resource associated with one or more subnets. Every subnet that needs inspection gets the same core UDR:

Route Table: rt-spoke1-subnets
Associated to: Spoke 1 subnet A, Spoke 1 subnet B

Routes:
  Name              Prefix          Next hop type        Next hop IP
  ─────────────────────────────────────────────────────────────────
  force-to-fw       0.0.0.0/0       Virtual Appliance    10.0.1.4

Deployed via ARM / Bicep:

resource routeTable 'Microsoft.Network/routeTables@2023-04-01' = {
  name: 'rt-spoke1-subnets'
  location: location
  properties: {
    disableBgpRoutePropagation: true   // ← critical — explained below
    routes: [
      {
        name: 'force-to-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.1.4'   // Azure Firewall private IP
        }
      }
    ]
  }
}

// Associate with spoke subnet
resource subnetAssociation 'Microsoft.Network/virtualNetworks/subnets@2023-04-01' = {
  name: 'spoke1/snet-app'
  properties: {
    addressPrefix: '10.1.1.0/24'
    routeTable: {
      id: routeTable.id
    }
  }
}

The Three Traffic Paths

Path 1 — North-South Outbound (spoke VM → internet)

Step 1: Spoke 1 VM (10.1.1.4) sends packet to 8.8.8.8
Step 2: Subnet route table consulted
        UDR match: 0.0.0.0/0 → next hop 10.0.1.4 (Firewall)
Step 3: Packet arrives at Azure Firewall private IP
Step 4: Firewall evaluates application rules
        Rule: allow src=10.1.0.0/16 dest=*.google.com proto=HTTPS → ALLOW
Step 5: Firewall SNATs packet
        Source IP changed: 10.1.1.4 → Firewall public IP (20.x.x.x)
Step 6: Packet exits to internet from Firewall public IP
        Return traffic arrives at Firewall public IP
Step 7: Firewall translates back → forwards to 10.1.1.4

SNAT is automatic for internet-bound traffic — the spoke VM’s private IP is never exposed to the internet. Azure Firewall’s public IP is the only address the internet sees.

Path 2 — North-South Inbound (internet → spoke VM)

Step 1: External client sends to Firewall public IP 20.x.x.x:443
Step 2: Firewall DNAT rule fires:
        dest 20.x.x.x:443 → translated to 10.1.4.5:443 (spoke VM)
Step 3: Firewall forwards to 10.1.4.5 via VNet peering path
Step 4: Packet arrives at spoke VM — no public IP needed on VM
Step 5: VM responds to Firewall private IP (it sees FW as source)
        UDR on VM subnet ensures return goes back through Firewall
Step 6: Firewall forwards return to external client

Path 3 — East-West (spoke 1 VM → spoke 2 VM)

This is the most important path for security — lateral movement between spokes must be inspected:

Step 1: Spoke 1 VM (10.1.1.4) sends packet to Spoke 2 VM (10.2.1.8)
Step 2: Spoke 1 subnet route table consulted
        UDR: 0.0.0.0/0 → 10.0.1.4 (matches — more specific than system route)
Step 3: Packet arrives at Azure Firewall
Step 4: Firewall evaluates network rules
        Rule: allow src=10.1.0.0/16 dest=10.2.1.8 port=443 → ALLOW
        (or deny if no rule matches)
Step 5: Firewall forwards to 10.2.1.8 via peering to Spoke 2
Step 6: Spoke 2 subnet route table:
        UDR: 0.0.0.0/0 → 10.0.1.4
        Return traffic: 10.2.1.8 → 10.1.1.4
        UDR forces return through Firewall too
Step 7: Firewall forwards return packet to Spoke 1 VM

Both directions of every connection traverse the Firewall — request and response. This is essential for stateful inspection — if only one direction went through the Firewall, the session state table would be incomplete.

disableBgpRoutePropagation — Why It Matters

Every route table has a disableBgpRoutePropagation flag. On spoke subnets this must be set to true:

disableBgpRoutePropagation: false (default)
  → VPN Gateway pushes on-premises routes into spoke effective routes
  → Spoke VM sends on-premises traffic directly to Gateway
  → Bypasses Firewall for on-premises bound traffic ❌
disableBgpRoutePropagation: true (required for spoke subnets)
  → VPN Gateway routes suppressed on spoke subnets
  → Only UDR routes active: 0.0.0.0/0 → Firewall
  → All traffic including on-premises bound goes through Firewall ✅

Forgetting this setting is one of the most common misconfiguration errors in hub and spoke deployments — on-premises traffic silently bypasses the Firewall even though the UDR looks correct.

UDR on GatewaySubnet — On-Premises to Spoke

To inspect traffic arriving from on-premises destined for spoke VNets, a UDR must also be applied to the GatewaySubnet:

Route Table: rt-gateway-subnet
Associated to: GatewaySubnet
Routes:
  Name            Prefix           Next hop type       Next hop IP
  ────────────────────────────────────────────────────────────────
  to-spoke1       10.1.0.0/16      VirtualAppliance    10.0.1.4
  to-spoke2       10.2.0.0/16      VirtualAppliance    10.0.1.4
  to-spoke3       10.3.0.0/16      VirtualAppliance    10.0.1.4

Note this uses specific spoke prefixes rather than 0.0.0.0/0 — applying a default route to GatewaySubnet breaks the gateway’s ability to communicate with Azure control plane endpoints.

Effective Route Inspection

You can verify UDRs are working correctly by checking a VM’s effective routes in the Azure portal or CLI:

az network nic show-effective-route-table \
  --resource-group rg-spoke1 \
  --name vm-prod-01-nic \
  --output table
Source    State    Address Prefix    Next Hop Type       Next Hop IP
────────  ───────  ────────────────  ──────────────────  ──────────
Default   Active   10.1.0.0/16       VnetLocal
Default   Invalid  0.0.0.0/0         Internet            ← overridden
User      Active   0.0.0.0/0         VirtualAppliance    10.0.1.4  ✅
Default   Active   10.0.0.0/16       VNetPeering
Default   Active   10.2.0.0/16       VNetPeering

The default 0.0.0.0/0 → Internet system route shows as Invalid — it has been overridden by the custom UDR pointing to the Firewall. This confirms all traffic is force-tunnelled correctly.

Common Misconfiguration Pitfalls

Forgetting disableBgpRoutePropagation — gateway-learned routes override UDRs for on-premises prefixes, silently bypassing Firewall for hybrid traffic.

Missing return path UDR — if Spoke 2 subnet has no UDR, return traffic goes directly back to Spoke 1 via peering, creating an asymmetric routing loop that breaks TCP sessions.

Applying UDR to AzureBastionSubnet — Bastion requires direct internet connectivity for its management plane. A UDR with 0.0.0.0/0 → Firewall on AzureBastionSubnet breaks Bastion entirely. Bastion subnet must have no UDR or a very specific one that excludes Bastion management ranges.

Applying 0.0.0.0/0 UDR to GatewaySubnet — breaks gateway health probes and control plane communication. Always use specific spoke prefixes on GatewaySubnet, never a default route.

Firewall private IP not static — Azure Firewall’s private IP should be configured as static during deployment. If it changes, every UDR next-hop entry becomes invalid and traffic black-holes.

Key Takeaway

The UDR is a deceptively simple mechanism — a single route entry 0.0.0.0/0 → Virtual Appliance → 10.0.1.4 — that transforms Azure’s default direct peering behaviour into a fully inspected, security-enforced network. Applied correctly to every spoke subnet with disableBgpRoutePropagation enabled, it ensures no traffic — outbound internet, inbound DNAT, or lateral east-west — can bypass Azure Firewall, giving you complete visibility and control over your entire hub and spoke estate.

Azure DDoS Protection Standard

Azure DDoS Protection Standard is a managed, always-on service that detects and mitigates volumetric, protocol, and application-layer DDoS attacks against your Azure public IP addresses — automatically, without any configuration changes during an attack.

The Three Attack Categories It Defends Against

Layer 3/4 — Volumetric attacks

These flood your network bandwidth with massive traffic volumes — UDP floods, ICMP floods, amplification attacks (DNS, NTP, memcached). Azure absorbs these at the network edge using its global 60+ Tbps scrubbing capacity, before the traffic ever reaches your VNet or gateway.

Layer 3/4 — Protocol attacks

These exhaust connection state tables on firewalls, load balancers, and gateways. SYN floods send millions of half-open TCP connections; Smurf attacks abuse ICMP broadcasts. DDoS Protection mitigates these by validating TCP handshakes and rate-limiting malformed packets at the edge.

Layer 7 — Resource layer attacks

HTTP floods, Slowloris, and application-specific attacks target your app’s compute rather than your bandwidth. DDoS Protection Standard alone does not fully mitigate Layer 7 attacks — these require Azure WAF on Application Gateway or Azure Front Door working alongside DDoS Protection. The two services are designed to be used together for full-stack protection.

How Adaptive Tuning Works

This is the core differentiator versus the free Basic tier. DDoS Protection Standard builds a per-public-IP traffic baseline using machine learning:

Normal Monday traffic profile for your VPN Gateway public IP:
  - Avg 2,000 packets/sec
  - Peak 8,000 packets/sec
  - Protocol mix: 70% TCP, 20% UDP, 10% ICMP
  - Geographic distribution: CA, US, EU
Attack detected when:
  - Packets jump to 4,000,000/sec  ← 500× normal
  - 99% from single ASN in one region
  - All UDP port 53 (DNS amplification)
Response: automatic mitigation within seconds
  - Rate limit traffic matching attack signature
  - Pass legitimate traffic through
  - Alert via Azure Monitor

Baselines are built per public IP, per protocol, per port — so the service understands what normal looks like for your VPN Gateway vs your Application Gateway vs your load balancer, and tuning is automatic as your traffic patterns change.

DDoS Protection Tiers Compared

Network Protection (the classic “Standard” tier) is applied at the VNet level via a DDoS Protection Plan — every public IP in all linked VNets is automatically covered.

IP Protection is a newer, per-IP option introduced for smaller deployments where you only need to protect a handful of public IPs without paying for a full plan.

What a DDoS Protection Plan Covers

A single DDoS Protection Plan can be linked to multiple VNets across multiple subscriptions in the same tenant. This is the right model for hub and spoke — one plan at the hub subscription level covers everything:

DDoS Protection Plan (resource group: rg-network-hub)
        ↓  linked to
Hub VNet          → VPN Gateway public IP protected
                  → Azure Firewall public IP protected
                  → Bastion public IP protected
Spoke 4 (DMZ)     → App Gateway public IP protected
                  → Load Balancer public IP protected

The first 100 public IPs are included in the plan price. Beyond 100, you pay per additional IP.

Monitoring and Alerting

During and after an attack, DDoS Protection surfaces detailed metrics in Azure Monitor:

Set an alert rule on Under DDoS attack = 1 to fire a notification to your security team or trigger a Logic App / n8n workflow the moment an attack begins.

When Should You Enable It?

Enable DDoS Protection Standard when any of these are true

Any public-facing production workload with real business impact if taken offline — an internet-facing Application Gateway, a VPN Gateway handling thousands of remote users, or a load balancer fronting a revenue-generating application — warrants the protection. The ~$3K/month cost is trivial compared to the revenue loss and incident response cost of a successful multi-hour DDoS attack.

You also need it when compliance frameworks require it. PCI-DSS, HIPAA, and ISO 27001 environments often require documented DDoS mitigation controls, and DDoS Protection Standard gives you the attack reports and flow logs needed to satisfy auditors.

The cost protection feature is a practical reason too — if an attack causes your Azure compute or bandwidth costs to spike (autoscaled VMs spun up to handle flood traffic, for example), Microsoft will credit those costs back when DDoS Protection was enabled.

You can skip it when

Dev/test environments, internal-only workloads with no public IPs, and resources entirely behind Azure Front Door or a third-party CDN that absorbs attacks upstream don’t need the plan — the Basic tier’s shared protection is sufficient, and the CDN/Front Door layer already absorbs volumetric attacks before they reach your origin.

In a Hub and Spoke Context

The recommended placement is one DDoS Protection Plan at the hub subscription, linked to the hub VNet and any spoke VNets that have public IPs (typically the DMZ spoke with App Gateway and WAF). Pair it with Azure Firewall for Layer 3/4 east-west filtering and Azure WAF on Application Gateway for Layer 7 protection, and you have defence-in-depth across all three attack categories.

Azure DNS Private Resolver

Azure DNS Private Resolver is a fully managed, highly available DNS service that lets your spoke VNets and on-premises networks resolve Azure private DNS zones — without deploying and managing DNS virtual machines.

Before Private Resolver existed, enterprises had to run Windows Server DNS VMs in the hub to forward queries between on-premises and Azure. Private Resolver replaces that entirely with a managed service.

The Two Endpoints

DNS Private Resolver has two endpoint types, each deployed into a dedicated delegated subnet inside the hub VNet.

Inbound Endpoint

Receives DNS queries from outside Azure — from on-premises DNS servers or spoke VNets that point their DNS server setting directly at this IP.

• Gets a static private IP from your hub VNet subnet (e.g. 10.0.5.4)
• Reachable over VPN Gateway or ExpressRoute from on-premises
• On-premises DNS servers forward specific zones (e.g. *.privatelink.blob.core.windows.net) to this IP
• Requires a dedicated /28 subnet named however you like (e.g. snet-dns-inbound)

Outbound Endpoint

Forwards DNS queries from Azure to external resolvers — typically to on-premises DNS servers for resolving internal corp domains like *.contoso.local.

• Also gets a private IP from a dedicated /28 subnet
• Does not receive queries directly — works only through a Forwarding Ruleset
• Requires a dedicated subnet separate from the inbound endpoint subnet

Forwarding Ruleset

A Forwarding Ruleset is a collection of conditional forwarding rules attached to the outbound endpoint. You then link the ruleset to spoke VNets so those spokes inherit the forwarding rules automatically.

Example ruleset rules

The wildcard . rule is the catch-all — any query that doesn’t match a specific rule falls through to Azure’s public DNS resolver.

How Spoke VNets Resolve Private DNS Zones

There are two patterns depending on whether you want centralised or per-VNet control.

Pattern 1 — Custom DNS server pointing to inbound endpoint (recommended)

Each spoke VNet sets its DNS server to the inbound endpoint’s private IP (10.0.5.4) instead of the default Azure DNS (168.63.129.16):

Spoke VM queries: myaccount.blob.core.windows.net
        ↓
Spoke VNet DNS setting → 10.0.5.4 (inbound endpoint)
        ↓
DNS Private Resolver checks private DNS zones
        ↓
Finds: myaccount.blob.core.windows.net → 10.1.8.4 (private endpoint IP)
        ↓
Returns private IP — traffic stays on private network

This is set at the VNet level in Azure portal or via ARM:

{
  "dhcpOptions": {
    "dnsServers": ["10.0.5.4"]
  }
}

Pattern 2 — Ruleset linked to spoke VNets

Link the hub’s forwarding ruleset directly to each spoke VNet. The spoke VNets keep the default Azure DNS (168.63.129.16) but inherit the conditional forwarding rules from the ruleset:

Spoke VM queries: server01.contoso.local
        ↓
Azure DNS (168.63.129.16) — checks linked ruleset
        ↓
Ruleset rule: contoso.local → forward to 192.168.1.10
        ↓
Outbound endpoint forwards to on-premises DNS
        ↓
On-premises DNS returns 192.168.10.45

Pattern 2 avoids changing the DNS server setting on every spoke and is easier to manage at scale — you just link new spokes to the existing ruleset.

Private DNS Zone Resolution Flow (Full Detail)

1. Developer VM in prod spoke queries:
   mydb.privatelink.database.windows.net
2. Query goes to 10.0.5.4 (inbound endpoint)
3. DNS Private Resolver checks:
   → Is there a forwarding rule for this domain? No
   → Is there a linked private DNS zone? Yes
     Zone: privatelink.database.windows.net
     Record: mydb → 10.1.9.6 (private endpoint NIC IP)
4. Returns: mydb.privatelink.database.windows.net = 10.1.9.6
5. VM connects to SQL on 10.1.9.6
   Traffic never leaves Azure backbone

Without DNS Private Resolver, the public DNS record for mydb.database.windows.net would resolve to the public IP, bypassing your private endpoint entirely.

Private DNS Zone Auto-Registration

When you create Azure PaaS resources with private endpoints, you link them to a private DNS zone. Common zones:

All these zones are linked to the hub VNet where DNS Private Resolver lives. Because all spokes resolve through the resolver, they automatically get the private IPs for these services.

Subnet Requirements

Both subnets must be in the hub VNet, must be separate from each other, and must not contain any other resources. The delegation is set automatically when you create the endpoint.

Before vs After Private Resolver

DNS Private Resolver is one of the clearest examples in Azure of a managed service eliminating operational overhead — the old pattern of DNS VMs in the hub was fragile, expensive, and easy to misconfigure.