Azure NSGs and Route Tables for Traffic Control

WHAT: this creates the NSG itself, then adds an inbound rule named allow-https at priority 100 permitting TCP traffic to destination port 443. WHY priority 100: Azure reserves 65000-65500 for its default rules and 100-4096 is the usable band for your own. Starting your most specific allow at 100 leaves room above it for even-more-specific exceptions later, and keeps it well ahead of the final DenyAllInBound at 65500. Priority ordering is the whole game, a rule that never gets evaluated because a broader rule matched first is indistinguishable from a rule that does not exist.

Every new NSG comes with three inbound defaults you did not write: AllowVNetInBound (65000), AllowAzureLoadBalancerInBound (65001), and DenyAllInBound (65500), plus a mirrored set for outbound. Your allow rule only has to land below 65000 in number to beat the catch-all deny. The full default set, for reference:

You cannot delete these defaults, you can only override them with lower-numbered rules, which is exactly what the lab does. For least privilege, also add an explicit deny for management ports from the internet so the intent is documented in the rule list, not just implied by the catch-all.

FULL RULE SET, allow 443, explicitly deny management ports

az network nsg rule create --nsg-name web-nsg -n allow-https \
  --priority 100 --direction Inbound --access Allow --protocol Tcp \
  --source-address-prefixes Internet --source-port-ranges '*' \
  --destination-address-prefixes 10.0.1.0/24 --destination-port-ranges 443

az network nsg rule create --nsg-name web-nsg -n deny-mgmt-internet \
  --priority 200 --direction Inbound --access Deny --protocol Tcp \
  --source-address-prefixes Internet --source-port-ranges '*' \
  --destination-address-prefixes '*' --destination-port-ranges 22 3389

Expected output:

{
  "name": "allow-https",
  "properties": {
    "access": "Allow",
    "destinationPortRange": "443",
    "priority": 100,
    "provisioningState": "Succeeded"
  }
}

Note the service tags used above: Internet is an Azure-defined tag representing all public address space, and it saves you from ever typing 0.0.0.0/0 as a source. The same mechanism offers VirtualNetwork, AzureLoadBalancer, and per-service tags like Storage.EastUS, using tags instead of hard-coded ranges keeps rules correct when Azure's own address space changes.

Inbound is only half of least privilege. The web tier also has no business initiating outbound connections to arbitrary internet hosts, so pin its egress down too: allow what the workload needs (here, Azure platform services and the app tier) and deny the rest. Outbound rules are evaluated with the same lowest-priority-first logic.

OUTBOUND LEAST PRIVILEGE, allow what is needed, deny the rest

az network nsg rule create --nsg-name web-nsg -n allow-out-app \
  --priority 100 --direction Outbound --access Allow --protocol Tcp \
  --source-address-prefixes 10.0.1.0/24 --source-port-ranges '*' \
  --destination-address-prefixes 10.0.2.0/24 --destination-port-ranges 8080

az network nsg rule create --nsg-name web-nsg -n deny-out-internet \
  --priority 4096 --direction Outbound --access Deny --protocol '*' \
  --source-address-prefixes '*' --source-port-ranges '*' \
  --destination-address-prefixes Internet --destination-port-ranges '*'

Why priority 4096 for the egress deny: it sits at the top of your usable band, still ahead of the default AllowInternetOutBound (65001) that would otherwise permit outbound internet access. Any future outbound allow you add lands between 100 and 4095 and beats the deny automatically.

An NSG that is not associated with anything filters nothing. Attach it to the web subnet so it applies to every NIC in that subnet:

ASSOCIATE THE NSG WITH THE WEB SUBNET

az network vnet subnet update --vnet-name lab-vnet -n web-subnet \
  --network-security-group web-nsg

VERIFY, the custom rules should list ahead of the defaults

az network nsg rule list --nsg-name web-nsg -o table

Name                Priority  Direction  Access  Protocol  DestinationPortRanges
------------------  --------  ---------  ------  --------  ---------------------
allow-https         100       Inbound    Allow   Tcp       443
allow-out-app       100       Outbound   Allow   Tcp       8080
deny-mgmt-internet  200       Inbound    Deny    Tcp       22, 3389
deny-out-internet   4096      Outbound   Deny    *         *

Common mistake: creating the rule against the wrong NSG name (every lab has at least one orphaned NSG from a previous attempt) or forgetting the subnet association. Verify with the table above, if your rule appears but traffic behavior does not change, the association is the first thing to check with az network vnet subnet show --vnet-name lab-vnet -n web-subnet --query networkSecurityGroup.

What this teaches: NSG rules evaluate by priority, lowest first; the first match wins, so ordering is the entire game.

A user-defined route overrides Azure's default routing so traffic must pass your inspection point.

WHAT: a route table named rt-app holding one route, to-fw, that sends all traffic matching 0.0.0.0/0 to next-hop type VirtualAppliance at 10.0.3.4. WHY: by default, Azure system routes give every subnet a direct path to the internet and to each other. The moment this UDR is associated with the app subnet, UDR precedence kicks in and the subnet's default route becomes the NVA, without logging into a single VM. This is the standard pattern for forced tunneling through a firewall, and VirtualAppliance is the next-hop type that requires an explicit IP (unlike Internet or VirtualNetworkGateway, which are symbolic).

To see what you are overriding, look at the effective routes before associating anything. Every route in the list is sourced Default, these are the system routes Azure builds automatically from the VNet's address space, and they are what any unmodified subnet follows:

BASELINE, system routes on an app-subnet NIC before the UDR

az network nic show-effective-route-table -n app01VMNic -o table

Source   AddressPrefix  NextHopType      NextHopIp
-------  -------------  ---------------  ----------
Default  10.0.0.0/16    VnetLocal
Default  0.0.0.0/0      Internet
Default  10.0.0.0/8     None
Default  172.16.0.0/12  None
Default  192.168.0.0/16 None

Expected output:

$ az network route-table route list -g tyf-rg --route-table-name tyf-rt -o table
Name         AddressPrefix    NextHopType       NextHopIpAddress
-----------  ---------------  ----------------  ------------------
to-firewall  0.0.0.0/0        VirtualAppliance  10.1.1.4

Two things to notice in the baseline. The Default 0.0.0.0/0 -> Internet line is the route your UDR is about to replace, after association, the same command shows that prefix sourced as User with the appliance as next hop. And the three RFC 1918 None routes outside your VNet's range are deliberate blackholes: Azure drops private-range traffic that does not belong to the VNet, which is why peered or on-prem networks need explicit routes rather than goodwill.

Choosing the next-hop type is the design decision in any UDR. The five options:

If the VNet is peered to an on-premises network over ExpressRoute or VPN, one more flag matters: BGP route propagation. A gateway can advertise routes (including a 0.0.0.0/0 from your on-prem edge) that would compete with your UDRs. Creating the table with propagation disabled makes the subnet deaf to those advertisements, so your UDRs are the only user intent in play:

HYBRID BONUS, create the table deaf to BGP advertisements

az network route-table create -n rt-app --disable-bgp-route-propagation true

In this standalone lab it makes no observable difference; in a hybrid environment it is the difference between a deterministic route table and one that changes when the on-prem router does.

Like the NSG, a route table does nothing until it is associated with a subnet. Associate it with the app subnet, and enable IP forwarding on the NVA's NIC, Azure drops packets delivered to a NIC whose IP is not the packet's destination unless forwarding is explicitly on. That Azure-side flag is separate from the OS-level forwarding inside the appliance, and you need both.

ASSOCIATE THE ROUTE TABLE AND ENABLE FORWARDING ON THE NVA

az network vnet subnet update --vnet-name lab-vnet -n app-subnet \
  --route-table rt-app

# Azure-side: allow the appliance NIC to receive packets not addressed to it
az network nic update -n fw01VMNic --ip-forwarding true

# OS-side (on the appliance itself, e.g. a Linux NVA):
#   sysctl -w net.ipv4.ip_forward=1
#   echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

VERIFY, route table contents and subnet association

az network route-table route list -g lab-rg --route-table-name rt-app -o table

Name   AddressPrefix  NextHopType       NextHopIpAddress
-----  -------------  ----------------  ------------------
to-fw  0.0.0.0/0      VirtualAppliance  10.0.3.4

Common mistake: pointing --next-hop-ip-address at the wrong interface of a multi-homed NVA (it must be an IP in a subnet the routing VM can reach, typically the appliance's trusted or LAN-side address), or forgetting that a route table can only be associated with subnets in the same region as the table. Also note that the address prefix is matched most-specific-first within the table: a 0.0.0.0/0 route is a catch-all, so any more specific route you add later for the same subnet wins over it.

What this teaches: A UDR overrides system routes by longest-prefix match; that is how you force traffic through inspection without touching the application.

WHAT: Azure merges system routes, your UDRs, and any BGP-learned routes into one effective route table per NIC, and merges all NSGs applied at the subnet and NIC level into one effective security rule view. WHY: this merged view is the ground truth. The individual resources can each look correct while the combination is wrong, a UDR on the wrong subnet, an old NSG still attached to a NIC, and the effective views are the only place where those composition errors become visible without sending traffic.

The Source column tells you where each route came from: Default for system routes, User for your UDRs, VirtualNetworkGateway for BGP-learned routes. In the output above, the User-sourced 0.0.0.0/0 entry confirms the UDR is associated and winning. Note this NIC-level command reflects the route table of the NIC's subnet, run it against a NIC in the app subnet (e.g. app01VMNic) to see the to-fw route in effect.

EFFECTIVE SECURITY RULES, the merged NSG view for a NIC

az network nic list-effective-nsg -n web01VMNic -o table

# For full detail, ask for the JSON and filter to inbound allows:
az network nic list-effective-nsg -n web01VMNic \
  --query "value[].association.networkSecurityGroup.id" -o tsv

Expected output:

$ az network nic show-effective-route-table -g tyf-rg -n tyf-vm01-nic -o table
Source   State   AddressPrefix    NextHopType       NextHopIpAddress
-------  ------  ---------------  ----------------  ------------------
Default  Active  10.1.0.0/16      VnetLocal
User     Active  0.0.0.0/0        VirtualAppliance  10.1.1.4
Default  Active  0.0.0.0/0        Internet

Both commands take a NIC, not a VM. If you only know the VM name, resolve its NICs first, a VM can have several, and each has its own effective views:

RESOLVE A VM'S NICS WHEN YOU ONLY KNOW THE VM NAME

az vm nic list --vm-name web01 -o table
az vm nic show --vm-name web01 --nic web01VMNic --query "ipConfigurations[].privateIPAddress"

Common mistake: running these commands immediately after a change and reading a stale view, effective views can take a minute to converge after an association change. If the output does not match what you just configured, wait 60-90 seconds and re-run before assuming the configuration is wrong. Also remember both commands target a NIC, not a VM: use az vm nic list -g lab-rg --vm-name web01 if you only know the VM name.

What this teaches: Effective rules and effective routes show the computed result, which is what actually applies, not what any single rule says.