Azure Virtual Networks, Subnets, Peering & User-Defined Routes

A VNet's address space is one or more CIDR blocks, normally from the RFC 1918 private ranges 10.0.0.0/8, 172.16.0.0/12 (172.16.0.0 to 172.31.255.255) and 192.168.0.0/16; watch the exact boundaries, because neighbours such as 172.32.0.0 or 192.169.0.0 are public space. You divide the address space into subnets: each subnet must sit inside one of the VNet's ranges and must not overlap another subnet. Plan every range so it overlaps nothing the VNet will ever connect to — on-premises networks, peered VNets, and networks reached through a hub's gateway — and size it for growth, not just today's machines, because re-addressing later is disruptive.

An address space does not have to be one block. A VNet can hold several non-contiguous ranges (for example 10.1.0.0/16 and 10.8.0.0/16), and you can add a range to an existing VNet to grow capacity without touching the subnets already deployed. Removing or shrinking a range is allowed only when no subnet uses the addresses being removed.

Azure reserves five IP addresses in every subnet: the network address (.0), the default gateway (.1), two addresses that map Azure DNS into the VNet (.2 and .3), and the last address of the range (broadcast). A /24 therefore gives 251 usable addresses, not 254, and the first address you can assign is .4. The smallest subnet Azure supports is a /29: 8 addresses minus 5 reserved leaves 3 usable.

Some services need a dedicated subnet with a fixed name: Azure Bastion uses AzureBastionSubnet, and VPN or ExpressRoute gateways use GatewaySubnet. You can add or delete subnets after creation, but you can change a subnet's address range only while no resources are deployed in it.

Most network controls in Azure attach to the subnet, and the subnet's settings page is where you associate them. A subnet can be associated with one network security group, one route table and one NAT gateway, and every resource in the subnet inherits them. Application security groups are the exception: they are assigned to a VM's network interface (NIC) IP configuration, not to a subnet, and are then referenced as sources or destinations in NSG rules (NSGs and ASGs are covered in the secure-access lesson).

Subnet delegation hands a subnet to a specific Azure PaaS service so that service can deploy its own resources and apply the network policies it needs. App Service VNet integration, for example, needs an empty subnet delegated to Microsoft.Web/serverFarms. A delegated subnet is reserved for that service; you do not put your own VMs in it.

Private IP addresses belong to the NIC's IP configuration in Azure, with allocation Dynamic (Azure picks the next free address) or Static (you choose an address that stays put). To give a VM a fixed private address, set the IP configuration to Static in the portal, CLI or template; the guest OS keeps using DHCP and receives that address. Typing a different address into the guest OS adapter does not change what Azure routes to the VM, so the VM loses connectivity — if you ever do configure addresses inside the OS (for example on a Windows VM with several IPs), they must match the addresses assigned in Azure. A static address must be free and must not be one of the subnet's five reserved addresses.

When a VM needs more than one private address in the same subnet — say an application server that needs a dedicated address for each service it hosts — add secondary IP configurations to the existing NIC. Each IP configuration carries its own private IP and can optionally carry its own public IP. One NIC can hold several IP configurations, so extra addresses don't require extra NICs (the number of NICs a VM supports is set by its size).

Virtual network peering joins two VNets so that resources in each can reach the other over private IP addresses, using the Microsoft backbone rather than the public internet. There is no gateway, no VPN tunnel and no encryption device in the data path. Regional peering connects VNets in the same Azure region; global peering connects VNets in different regions. Peering also works across resource groups, subscriptions and Microsoft Entra tenants, and the only hard prerequisite on the networks themselves is that their address spaces must not overlap — an overlap blocks peering creation, and the fix is to re-address one VNet.

Peering is not transitive. If spoke A and spoke C are each peered to hub B, A still cannot reach C: each peering adds routes only for the two VNets it joins. Every pair of VNets that must talk directly needs its own peering, or you must route the traffic through a device in the hub (see the next section).

A peering is really two links, one created on each VNet, and the status reads Initiated after the first link and Connected only when both exist. Each link is created by someone with peering permissions on that VNet (for example Network Contributor). Across tenants, the administrator either holds rights in both tenants (typically as a guest user in the other tenant) or each side's administrator creates its own link. Without rights on the remote VNet you can create only your own link; the portal creates both links in one step only when you hold permissions on both VNets. Deleting the peering in the portal (with rights on the remote VNet) removes both links, while PowerShell and the CLI delete each link separately; once a link is gone, the peering routes disappear and traffic between the VNets stops.

Each peering link carries settings that decide which traffic the VNet owning that link accepts or offers. Allow virtual network access (on by default) lets the two VNets communicate.

Allow forwarded traffic controls whether a VNet receives traffic that did not originate in the peered VNet — for example packets that a firewall or NVA in the hub relays from one spoke to another. Because the setting governs what the receiving VNet admits, it belongs on each spoke's peering to the hub when spokes communicate through a hub appliance: traffic from Spoke1 that the hub firewall relays arrives at Spoke2 as forwarded traffic, so Spoke2's link must allow it. The setting does nothing for traffic that starts in the peered VNet, and it does not advertise any routes.

Allow gateway transit and Use remote gateways work as a pair. The VNet that owns a VPN or ExpressRoute gateway (the hub) sets Allow gateway transit on its link; the spoke sets Use remote gateways on its link and then learns the on-premises routes through the hub's gateway instead of deploying its own. Both regional and global peering support gateway transit. A VNet that uses a remote gateway cannot have its own gateway, and only one of a VNet's peerings can have Use remote gateways enabled.

Spoke-to-spoke connectivity has two designs. A direct peering between the two spokes gives the lowest latency and puts no load on a hub device. Service chaining sends spoke-to-spoke traffic through the hub: user-defined routes in each spoke point the other spoke's prefix at a hub NVA or firewall (next hop Virtual appliance) or at the hub's VPN gateway (next hop Virtual network gateway), and the spoke links allow forwarded traffic. Chaining centralises inspection but adds a hop. Gateway transit by itself does not connect spokes: it shares on-premises routes with each spoke, not one spoke's prefixes with another.

You can change the address space of a VNet that is already peered — add a range, remove an unused range, or resize one — without deleting the peering and without downtime. Deleting and recreating peerings is the old, disruptive approach and is no longer needed.

After the change, the peered VNets still hold the old prefixes until you sync the peering: on each remote VNet's peering link to the changed VNet, run Sync (portal) or the equivalent sync operation in the CLI or PowerShell, so the remote side learns the new ranges. Sync after every resize operation rather than batching several changes into one sync. This works for regional, global and cross-tenant peerings; for a cross-tenant peer, an administrator with rights on the remote VNet runs the sync on that side.

The usual address-space rules still apply: a range you remove or shrink must not be in use by a subnet, and the new ranges must not overlap any peered or connected network.

A public IP address is a separate Azure resource that you associate with a VM NIC's IP configuration, a load balancer front end, a VPN gateway, Azure Bastion or a NAT gateway. You can associate a public IP with an existing VM's NIC at any time — open the NIC's IP configuration and attach it; the VM does not need to be recreated.

Basic SKU public IPs were retired on 30 September 2025, so new deployments that request Basic (with its dynamic allocation option) fail. Dynamic public IPs were a Basic-only behaviour: the address was released when the VM was stopped (deallocated) and could change on restart, which is why older questions mention it. Use the Standard SKU, which is always statically allocated — the address is fixed for the life of the resource, which is what DNS records and allowlists need.

Standard public IPs are secure by default: inbound internet traffic is blocked until a network security group on the NIC or subnet allows it. A VM with a Standard IP and no NSG can make outbound connections, but inbound connections time out until you add an NSG allow rule for the port.

Zone configuration is the other decision. A zone-redundant Standard IP survives a single availability-zone failure; a zonal IP is pinned to one zone and fails with it. In regions with availability zones, Standard IPs created without a zone setting are now zone-redundant by default. The newer Standard v2 SKU is zone-redundant only and, at present, can be used only with the Standard v2 NAT gateway — it cannot be attached to a VM NIC.

A NAT gateway gives a subnet outbound-only internet connectivity through its public IPs. It never admits connections initiated from the internet, so it is not a way to make a VM reachable; for inbound access use a public IP on the NIC or a load balancer.

Azure creates system routes for every subnet: the VNet's own address space (next hop Virtual network), peered VNets (VNet peering), 0.0.0.0/0 to Internet, and routes with next hop None for 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10. Those None routes mean that a private destination with no more-specific VNet, peering or gateway route is dropped, not sent to the internet — for example, a VM addressing a 192.168.x.x on-premises host before any VPN connection advertises that range hits the 192.168.0.0/16 None route. BGP routes from a VPN or ExpressRoute gateway are added too. You cannot delete system routes, but you can override them with user-defined routes (UDRs) in a route table associated with a subnet. A route table changes the path of traffic leaving the subnets it is associated with.

A route has an address prefix and a next hop type: Virtual appliance (with the appliance's private IP), Virtual network gateway, Virtual network, Internet or None (drop).

How Azure picks a route: first the longest prefix match wins, whatever its source. Only when two routes have an identical prefix does the source decide: user-defined > BGP > system. So a BGP-learned 172.20.4.0/24 beats a UDR for 172.20.0.0/16, while a UDR for exactly 10.2.0.0/16 overrides the system peering route for the same prefix. The overridden route is not removed; it stays in the NIC's effective routes with state Invalid, and the winner shows Active.

Gateway routes: a route table's Propagate gateway routes setting decides whether subnets using it receive BGP routes from the VPN or ExpressRoute gateway. Set to No, those subnets get no on-premises routes even though the VNet uses gateway transit — sibling subnets without that table still do. A UDR with next hop Virtual network gateway works only with a VPN gateway. To force-tunnel internet traffic over ExpressRoute, advertise 0.0.0.0/0 from on-premises over the BGP session instead.

Inspecting traffic inside one VNet: a 0.0.0.0/0 UDR never catches destinations inside the VNet, because the more specific Virtual network system route wins. To send traffic between two subnets through an appliance, add a more-specific route on both subnets — on the first, the second subnet's prefix to the appliance, and on the second, the first's prefix — so return traffic passes the appliance too (symmetric routing); stateful firewalls drop asymmetric flows.

Your security team requires every packet leaving the App subnet for the internet to be inspected by a third-party firewall VM. The firewall lives in its own Security subnet with private IP 10.0.2.4.

First, enable IP forwarding on the firewall's NIC (and in its OS) so it can accept packets not addressed to itself; without it Azure drops the relayed packets. Second, create a route table with a UDR for 0.0.0.0/0, next hop type Virtual appliance, next hop address 10.0.2.4. Third, associate the route table with the source subnet — App — and with any other subnet whose traffic must be inspected, but never with the appliance's own subnet: the route would apply to the firewall's outbound traffic as well and loop it back to itself, cutting off internet access for everything behind it. Keeping the NVA in a dedicated subnet is what makes this possible.

If the App subnet is in a spoke and the firewall in the hub, the same route works across the peering. For spoke-to-spoke traffic through the hub firewall, add routes for the other spoke's prefix and enable Allow forwarded traffic on each spoke's peering to the hub. To confirm the design, check the App VM NIC's Effective routes: your 0.0.0.0/0 user route should be Active and the system Internet route Invalid.

When traffic will not flow, separate filtering problems from routing problems, and Network Watcher has a tool for each (Network Watcher and Connection monitor are covered in more depth in the monitoring lessons).

IP flow verify says whether a specific flow (source and destination IP, port, protocol, direction) is allowed or denied by NSG rules and names the rule responsible. If it says allowed and traffic still fails, the problem is usually routing.

Next hop shows where Azure sends a packet from a VM to a given destination: the next hop type, the next hop IP, and a route table ID when a user-defined route matched (otherwise it reports a system route). Read it like this: next hop type None means the packet is dropped. None with a route table ID means a UDR in that table discards the traffic; None without one means a default system None route matched — typically a private destination with no VNet, peering or gateway route, such as an on-premises range that no gateway advertises yet. Virtual appliance with a route table ID shows a UDR diverting traffic to an NVA.

Effective routes, on the VM's network interface, lists every route applied to that NIC — sources Default (system), Virtual network gateway (BGP) and User — each with state Active or Invalid, so you can see which route wins and which are overridden. The route table's own Routes page shows only the UDRs you created, not the combined picture. Effective security rules does the same for the combined NSG rules.

Connection troubleshoot and Connection monitor test reachability end to end and report latency and the hop where a connection fails. A practical order: IP flow verify to rule out NSGs, then Next hop and Effective routes to rule out routing, then Connection troubleshoot for the full path.