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

When you create a virtual network you first define its address space as one or more private CIDR blocks, such as 10.0.0.0/16. You then divide that space into subnets, and each subnet must be a subset of the VNet range and must not overlap with another subnet. Plan the address space so it does not overlap with your on-premises network or any VNet you intend to peer with, because overlapping ranges make peering impossible.

The classic exam fact is that Azure reserves five IP addresses in every subnet. In a 10.0.0.0/24 subnet, Azure takes the network address 10.0.0.0, the default gateway 10.0.0.1, two addresses (10.0.0.2 and 10.0.0.3) that map to Azure DNS, and the broadcast address 10.0.0.255. That leaves 251 usable host addresses out of 256, not 254. Always subtract five when you size a subnet for a fixed number of machines.

Some services need their own dedicated subnet, and the name matters: Azure Bastion needs a subnet literally named AzureBastionSubnet, and a VPN or ExpressRoute gateway needs a GatewaySubnet. You can add, resize, or delete subnets after creation as long as no resource is using the affected range.

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 overhead in the data path. Peering comes in two forms. Regional (local) peering connects two VNets in the same Azure region. Global peering connects VNets in different regions, letting a VNet in East US talk privately to one in West Europe.

Peering is not transitive. This is the single most tested peering fact. If you peer VNet A to hub VNet B, and separately peer VNet B to VNet C, traffic still does not flow between A and C. Each pair needs its own peering, or you must route through a network virtual appliance in the hub using user-defined routes. A hub-and-spoke topology relies on exactly this behaviour: spokes reach the hub but not each other unless you deliberately route them.

You configure peering from both sides — a peering link on VNet A and a matching link on VNet B — and the connection status only shows Connected when both links exist. The two address spaces must not overlap.

Each peering link exposes options that change what traffic is allowed and how remote networks are reached. Understanding them separates a passing answer from a guess.

Allow virtual network access is on by default and simply lets the two peered VNets communicate. Allow forwarded traffic permits traffic that did not originate in the peered VNet — for example, traffic that a network virtual appliance forwards on behalf of another network. You enable this on the hub side when spokes send traffic through a firewall in the hub.

Allow gateway transit and Use remote gateways work as a pair for hub-and-spoke designs. If the hub VNet holds a VPN or ExpressRoute gateway, you set Allow gateway transit on the hub's peering and Use remote gateways on the spoke's peering. The spoke then uses the hub's gateway to reach on-premises networks instead of deploying its own gateway, which saves cost and centralises connectivity. Only one VNet in a peering can use the remote gateway, and the spoke must not already have its own gateway. Remember that these options are set per link, so you configure the transit side and the consuming side separately.

A public IP address is a separate Azure resource you associate with a VM's network interface, a load balancer, a VPN gateway, Bastion, or a NAT gateway to allow inbound or outbound internet connectivity. Two decisions define it: the SKU and the allocation method.

The SKU is either Basic or Standard. A Standard public IP is always statically allocated, is secure by default (closed to inbound traffic until a network security group rule allows it), and supports availability zones. A Basic public IP can be static or dynamic and is open by default. Microsoft is retiring Basic SKU public IPs, so choose Standard for new production workloads; Standard is also required by the Standard Load Balancer.

The allocation method is static or dynamic. A dynamic address is assigned when the resource starts and released when it stops or deallocates, so it can change. A static address is reserved immediately and stays fixed for the life of the resource, which you want for DNS records, firewall allowlists, or anything that must not change. Note the SKU constraint: Standard is static-only, so the choice of SKU can decide the allocation for you.

Azure automatically creates system routes so that subnets can reach each other, the internet, and peered or on-premises networks without any configuration. You cannot delete system routes, but you can override them with a user-defined route (UDR) placed in a route table that you associate with a subnet.

A route specifies an address prefix (the destination) and a next hop type. The next hop types are Virtual appliance, Virtual network gateway, Virtual network, Internet, and None. When a packet's destination matches a route, Azure uses the most specific prefix; where a UDR and a system route are equally specific, the UDR wins. Choosing None drops the traffic entirely.

The signature use of a UDR — and the answer whenever a question says "force traffic through a firewall appliance" — is to set a route for 0.0.0.0/0 with next hop type Virtual appliance and the private IP of a firewall or NVA. That sends all outbound subnet traffic to the appliance for inspection before it leaves. For this to work you must also enable IP forwarding on the appliance's network interface, or Azure will drop the forwarded packets.

Your security team requires that every packet leaving the App subnet be inspected by a third-party firewall virtual machine before it reaches the internet. The firewall VM lives in a Security subnet with the private IP 10.0.2.4. Here is how you satisfy the requirement as an administrator.

First, deploy the firewall VM and, on its network interface, turn on IP forwarding so it can accept packets not addressed to itself. Second, create a route table and add a UDR with address prefix 0.0.0.0/0, next hop type Virtual appliance, and next hop address 10.0.2.4. Third, associate the route table with the App subnet. From that moment, the App subnet's default route to the internet is overridden, and all outbound traffic is steered to the firewall for inspection.

If you also want the firewall to inspect traffic between the App subnet and a peered spoke, remember peering is non-transitive: add matching routes and enable Allow forwarded traffic on the relevant peering links. To confirm the design works, open Network Watcher and check Effective routes on the App VM's NIC — you should see your 0.0.0.0/0 route pointing at the appliance, superseding the system Internet route.

When traffic will not flow, Network Watcher is the toolbox the exam expects you to reach for. It is a regional service, and its diagnostics answer the common "why is this blocked?" questions without guesswork.

IP flow verify tells you whether a specific 5-tuple (source and destination IP, ports, and protocol) is allowed or denied, and if denied, it names the exact security rule responsible — the fastest way to catch an NSG that is blocking traffic. Next hop shows where Azure will send a packet bound for a given destination, revealing whether a UDR is diverting traffic unexpectedly. Effective routes lists every route applied to a network interface after system routes, UDRs, and peering are combined, so you can confirm your custom route is winning. Effective security rules does the same for the combined NSG rules on a NIC.

Connection troubleshoot and Connection monitor actively test reachability between a source and a destination and report latency and the hop where a connection fails. A practical order of attack is: run IP flow verify to rule out NSGs, then check Next hop and Effective routes to rule out routing, then use Connection troubleshoot to test the end-to-end path.