7.2 VNet Peering and Cross-Network Connectivity

What peering provides

VNet peering connects two Azure virtual networks so resources can communicate by private IP across Microsoft's backbone. It can be used within a region or across regions. It does not require public IPs on the workload VMs, and it does not send traffic over the public internet. For AZ-104, peering is a common answer when two Azure VNets need private connectivity and their address spaces do not overlap.

A peering relationship is effectively configured in both directions. In the portal, creating a peering can create both links when you have permissions to both VNets. In scripts, you may create each side separately. If only one side is present or one side is disconnected, traffic does not behave as intended.

Basic model:

VNet-A 10.10.0.0/16  <==== peering ==== >  VNet-B 10.20.0.0/16
VM-A  10.10.1.4                         VM-B  10.20.1.4

When peering is healthy and no NSG or route blocks traffic, VM-A can reach VM-B by 10.20.1.4. No public IP is required. If the question asks for private connectivity between Azure VNets with low administrative overhead, peering is usually a stronger answer than deploying a VPN gateway between the VNets.

Peering is not transitive

The major exam trap is transitivity. If VNet-A is peered with VNet-Hub, and VNet-Hub is peered with VNet-B, VNet-A is not automatically peered with VNet-B. Traffic from A to B needs direct peering, a network virtual appliance, Azure Firewall routing, VPN routing, or another explicit design.

Hub-and-spoke diagram:

                 on-premises
                     |
                 VPN gateway
                     |
              hub-vnet 10.0.0.0/16
              /                  \
spoke-web 10.1.0.0/16      spoke-data 10.2.0.0/16

In this design, each spoke peers with the hub. If web and data spokes must communicate through a firewall in the hub, you must configure routes that send traffic to the firewall and peering options that allow forwarded traffic. If the spokes should not communicate, do not create direct peering and do not route them through the firewall.

Gateway transit and remote gateways

Gateway transit lets a peered VNet use a gateway in another VNet, commonly the hub. The hub peering side allows gateway transit. The spoke peering side uses the remote gateway. This is an AZ-104 favorite because the settings are paired and directional.

A spoke VNet cannot use a remote gateway and also have its own virtual network gateway. In exam wording, if a spoke already has a gateway, using the hub gateway through remote gateway is not available unless the design changes.

Forwarded traffic and route design

Forwarded traffic means traffic that did not originate in the peered VNet but is being passed through it. A common example is traffic from spoke-web to spoke-data through Azure Firewall in the hub. The firewall forwards packets, so peering must allow forwarded traffic where required. A UDR on the spoke subnets may send traffic for the other spoke prefix to the firewall private IP.

Example route table entry on spoke-web workload subnet:

This route only changes the next hop. It does not automatically allow the traffic. The NSGs on source and destination subnets, firewall policy, VM host firewall, and return route must also permit the flow.

Portal and CLI workflow

Portal path: Virtual networks > <vnet> > Peerings > Add. Review the local VNet settings, remote VNet settings, traffic to remote virtual network, forwarded traffic, gateway transit, and remote gateway options. After creation, check that the peering status is connected on both sides.

CLI outline:

az network vnet peering create \
  --resource-group rg-network \
  --name hub-to-spoke-web \
  --vnet-name hub-vnet \
  --remote-vnet spoke-web-vnet \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --allow-gateway-transit

az network vnet peering create \
  --resource-group rg-network \
  --name spoke-web-to-hub \
  --vnet-name spoke-web-vnet \
  --remote-vnet hub-vnet \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --use-remote-gateways

Troubleshooting peered connectivity

Use a layered workflow. First, confirm the address spaces do not overlap. Second, confirm peering exists and is connected on both sides. Third, check whether the target IP is correct and whether DNS resolves to the expected private address. Fourth, inspect effective routes on the source NIC. Fifth, inspect effective security rules on both source and destination NICs. Sixth, test the VM operating system firewall or application listener.

Network Watcher tools help here. IP flow verify can tell whether an NSG allows or denies a packet. Next hop can show whether Azure sends the packet to a peering, virtual appliance, internet, or none. Connection troubleshoot can test a specific endpoint and port.

Troubleshooting tree:

Can source resolve the name?
  no -> check private DNS, custom DNS, host records
  yes -> does the resolved IP belong to reachable VNet prefix?
       no -> fix DNS or endpoint configuration
       yes -> check effective route next hop
            next hop missing -> peering or route issue
            next hop firewall -> inspect firewall policy and return route
            next hop peering -> inspect NSG and guest firewall

Scenario traps

Do not choose peering if address spaces overlap. Do not assume peering makes all hub-connected spokes talk to each other. Do not forget both sides of gateway transit. Do not allow remote gateway on a spoke that already has its own gateway. Do not assume public DNS names resolve to private IPs just because peering exists.

A frequent case study says that a VM in a spoke cannot reach an on-premises server through the hub VPN gateway. The likely checks are hub peering allows gateway transit, spoke peering uses remote gateway, routes are learned or configured, NSGs allow the traffic, and on-premises routes return to Azure. Creating a public IP on the VM is not the right fix for private hybrid connectivity.