🛸 Hitchhiker's Guide — Phase 06: Azure Networking & the SDN

Read this if: you can click "create virtual network" but a dropped packet still feels like witchcraft. It isn't — it's three algorithms (NSG priority, route longest-prefix, Private DNS) and a subnet-math rule. This is the compressed tour the WARMUP derives slowly. Skim it, then read the WARMUP, then build the engine.

0. The 30-second mental model

A packet in Azure passes four gates, and a drop is always one of them — silently, with no log unless you turned on flow logging:

(0) DNS        what IP is the dest?      ← Private Endpoint rewrites this; #1 failure
(1) src NSG    may it leave?             ← priority order, first match wins, stateful
(2) route      where's the next hop?     ← longest-prefix match; UDR > BGP > system
(3) dst NSG    may it arrive?            ← same NSG rules, at the destination

One sentence to tattoo: the Azure network is software — NSGs, routes, and DNS are algorithms on the host, and when something breaks it's almost always NSG priority, route longest-prefix, or Private DNS.

1. The numbers to tattoo on your arm

Subnet cheat row: /24=251, /26=59, /27=27, /28=11, /29=3 usable.

2. NSG in one breath

• Rules have a priority 100–4096; Azure sorts ascending and stops at the first match. Low number wins. A Deny at 100 shadows an Allow at 200.
• Stateful: allow the outbound flow and the return is automatic. Never write a return rule (it's a smell).
• Defaults (can't delete): allow VirtualNetwork↔VirtualNetwork, allow AzureLoadBalancer in, allow Internet out, deny the rest. So: intra-VNet is open by default; inbound-from-internet is closed by default.
• Service tags save you from hardcoding Microsoft IPs: VirtualNetwork, Internet, AzureLoadBalancer, Storage, Sql, Storage.WestEurope, …

3. Routes in one breath

• Effective table = system + UDR + BGP, computed per NIC.
• Longest-prefix match picks the next hop. /32 beats /24 beats /0.
• Equal prefix → UDR > BGP > system. That's why a UDR 0.0.0.0/0 overrides the default.
• Force all egress through a firewall: UDR 0.0.0.0/0 → VirtualAppliance @ fw-private-ip.
• Next-hop types: VirtualAppliance (needs IP), VnetLocal, Internet, VirtualNetworkGateway, VnetPeering, None (blackhole — silent drop).

4. Private Link in one breath

• A Private Endpoint = a NIC + private IP in your subnet, mapped to a PaaS resource.
• It only works because of a DNS override: acct.blob.core.windows.net → privatelink.blob.core.windows.net zone → private IP — but only if that zone is linked to your VNet.
• The bug: zone not linked → name still resolves to the public IP → connection fails (public access disabled) or silently leaves the private net.
• Service endpoint = the lighter alternative: backbone routing + subnet trust, but no private IP, no DNS change, no on-prem.

5. az one-liners worth memorising

# Subnet usable check — what's the next hop / effective rules for a NIC? (the real debug)
az network nic show-effective-route-table -g RG -n my-nic -o table
az network nic list-effective-nsg-rules   -g RG -n my-nic -o table

# Create the spine
az network vnet create -g RG -n hub --address-prefixes 10.0.0.0/16 \
  --subnet-name AzureFirewallSubnet --subnet-prefixes 10.0.0.0/26
az network nsg create -g RG -n app-nsg
az network nsg rule create -g RG --nsg-name app-nsg -n AllowHTTPS \
  --priority 200 --direction Inbound --access Allow --protocol Tcp \
  --source-address-prefixes Internet --destination-port-ranges 443

# Force egress through a firewall (the UDR)
az network route-table create -g RG -n spoke-rt
az network route-table route create -g RG --route-table-name spoke-rt -n default \
  --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.0.4

# Private DNS — the thing people forget to LINK (the #1 fix)
az network private-dns zone create -g RG -n privatelink.blob.core.windows.net
az network private-dns link vnet create -g RG -n spoke-link \
  --zone-name privatelink.blob.core.windows.net --virtual-network spoke --registration-enabled false

# Peering (non-transitive; non-overlapping CIDRs required)
az network vnet peering create -g RG -n hub-to-spoke --vnet-name hub \
  --remote-vnet spoke --allow-vnet-access

# The first command in ANY "Private Endpoint not working" ticket — run it ON the VM:
nslookup acct.blob.core.windows.net     # private IP = good; public IP = unlinked zone

6. War story shapes you'll relive

• "The Private Endpoint is green but the app hits the public IP." → the Private DNS zone was never linked to that spoke VNet (or a custom DNS server doesn't forward privatelink.*). nslookup on the VM tells you instantly. Fix the link, not the data path.
• "My Allow rule isn't working." → a lower-priority Deny (smaller number) shadows it. First match wins. Sort the rules by priority and read top-down.
• "The whole spoke lost internet at once." → a 0.0.0.0/0 UDR force-tunnels to a firewall that's down/misrouted — every egress blackholes. Check the effective route table's next hop.
• "These two VNets refuse to peer." → overlapping CIDRs. You can't peer 10.0.0.0/16 with 10.0.0.0/16. Re-IP one (a one-way door — plan addresses up front).
• "A talks to B, B talks to C, but A can't reach C." → peering is non-transitive. Route A↔C through the hub (and its firewall) on purpose.
• "I blocked it with an inbound deny but return traffic still flows." → NSGs are stateful; you're fighting connection tracking. Block the originating direction.

7. Vocabulary that signals you've held the pager

• Effective rules / effective routes — the computed result for a NIC; what you actually debug (show-effective-*), not the rule you wrote.
• Longest-prefix match — the route selection algorithm; /32 beats /0.
• Force tunnelling — UDR 0.0.0.0/0 → firewall; all egress inspected.
• Force-tunnel blackhole — that same UDR pointed at a dead next hop.
• Privatelink zone / VNet link — the DNS objects that make Private Endpoints actually private; the link is the thing people forget.
• Service tag — symbolic prefix set (VirtualNetwork, Internet, Storage.WestEurope).
• Non-transitive peering — A↔B + B↔C ≠ A↔C.
• Hub-and-spoke — central firewall/gateway/DNS, peered spokes, UDR to the firewall.
• ASG (Application Security Group) — name a role and write NSG rules against it.

8. Beginner mistakes that mark you in interviews

1. Saying "higher priority number wins" — it's lower.
2. Writing an inbound rule for return traffic — NSGs are stateful.
3. Thinking a Private Endpoint is private the moment it's created — it's the DNS link.
4. Assuming the network spans regions or that any two VNets can peer — regional, and non-overlapping CIDRs only.
5. Forgetting the 5 reserved IPs and the /29 floor in subnet math.
6. Putting WAF/TLS termination on the L4 Load Balancer — that's the L7 layer (Front Door / App Gateway).
7. Force-tunnelling 0.0.0.0/0 to a firewall with no return/SNAT path and blackholing it.

9. How this phase pays off later

• P07 (AKS/ACR): pods get IPs from the VNet (Azure CNI); NSGs and Private Endpoints to ACR are exactly these engines. Your subnet math sizes the node pools.
• P10–P12 (events, serverless, Key Vault): every secure deployment is **Private Endpoint
  • Private DNS** — the resolver you built here.
• P14 (reliability): a hub firewall / gateway is a failure domain; zone-redundancy and break-glass routes are blast-radius decisions on this topology.
• Every interview: NSG priority and longest-prefix routing are the two most-asked Azure networking questions, and "why doesn't my Private Endpoint work" is the most-asked debug.

Now read the WARMUP slowly (do the subnet math by hand), then build the network engine. You'll use these four algorithms to read effective-rules dumps for the rest of your career.