VNet Connectivity and Routing
Azure routing is based on system routes, BGP routes, and user-defined routes. More specific prefixes win. User-defined routes can override default system routing and are used for forced tunneling, firewall inspection, and NVA paths.
VNet Peering
- Peering connects VNets over the Microsoft backbone.
- Peered VNets cannot have overlapping address spaces.
- Gateway transit allows a spoke to use a gateway in a hub VNet.
- Peering is not transitive by default. Hub routing requires explicit peering and route design.
Gateway Transit Across VNet Peerings
Gateway transit lets a spoke VNet use a VPN or ExpressRoute gateway deployed in a peered hub. The settings are directional. On the hub-to-spoke peering, enable Allow gateway transit, shown in newer portal wording as using this virtual network's gateway or Route Server. On the spoke-to-hub peering, enable Use remote gateways. The spoke then learns routes through the hub gateway without deploying another gateway.
A spoke that uses a remote gateway cannot also have its own virtual network gateway, and a VNet can use only one remote gateway. Peering itself remains non-transitive: connecting Spoke1 to Hub and Spoke2 to Hub does not automatically create general Spoke1-to-Spoke2 routing. Use explicit peering, Virtual WAN, Virtual Network Manager connectivity, or an NVA and UDR design when spoke transit is required. Enable forwarded traffic where traffic reaches a peering from a gateway or appliance rather than originating in the directly peered VNet.
Cross-Subscription Peering
VNets can be peered across subscriptions when permissions exist on both VNets. The relationship still consists of two directional peering objects, one in each VNet. Subscription count does not by itself require additional gateways or circuits; address overlap, region and SKU reach, topology limits, ownership boundaries, and throughput are the actual design constraints. See gateway transit with VNet peering.
Azure Virtual Network Manager
Virtual Network Manager helps centrally manage connectivity and security admin rules across many VNets. For AZ-700, know that it can create network groups, connectivity configurations, mesh or hub-spoke topology, and security admin rules.
User-Defined Routes and Forced Tunneling
| Route | Next hop | Use case |
|---|---|---|
| 0.0.0.0/0 | Virtual appliance | Force internet-bound traffic through Azure Firewall or an NVA. |
| On-premises prefix | Virtual network gateway | Send traffic to a VPN or ExpressRoute gateway. |
| Specific app prefix | Virtual appliance | Inspect or redirect traffic for a specific subnet or app tier. |
Azure Route Server
Route Server exchanges routes dynamically between Azure and NVAs using BGP. Use it when static UDRs become operationally painful or when NVA route advertisement must adapt automatically.
NAT Gateway
NAT Gateway provides managed outbound SNAT for a subnet. It is generally the cleanest answer for stable outbound public IP addresses from private resources. Associate it to a subnet and attach one or more public IPs or public IP prefixes.
Monitoring and Troubleshooting
- Use Network Watcher IP flow verify to confirm whether a flow is allowed or denied.
- Use effective security rules to see the actual NSG result on a NIC.
- Use effective routes and next hop to troubleshoot route selection.
- Use connection troubleshoot to validate connectivity between endpoints.
- Use packet capture when you need packet-level evidence.
- Use topology views and Azure Monitor for Networks for broader network health.
DDoS Protection
Azure DDoS Protection protects public IP resources. Know when to enable network protection, how to monitor attack telemetry, and how DDoS recommendations appear in Defender for Cloud.
Lab
- Create hub-spoke peering and enable gateway transit settings.
- Create a route table with a default route to a firewall or NVA.
- Attach NAT Gateway to a workload subnet and verify outbound IP.
- Use Network Watcher next hop and effective routes to explain the path.
Feature Deep Dive
Route Selection
Azure chooses routes by longest prefix match first. If two routes have the same prefix length, route source priority matters. User-defined routes normally override system routes, and BGP routes can introduce hybrid paths from VPN or ExpressRoute. This is why a single 0.0.0.0/0 UDR can change the entire outbound behavior of a subnet.
Forced Tunneling
Forced tunneling sends internet-bound traffic to a next hop such as Azure Firewall, a third-party NVA, or an on-premises gateway. The exam often describes this as "all outbound traffic must be inspected" or "internet traffic must leave through the corporate network." The answer is usually a route table with a default route plus the correct next hop architecture.
NAT Gateway Behavior
NAT Gateway attaches to a subnet and becomes the preferred outbound SNAT path for resources in that subnet. It is not an inbound publishing service. Use it when workloads need stable outbound IPs, higher SNAT scale, and simple outbound internet access without assigning public IPs to VMs.
Monitoring Stack
Network Watcher is for tactical troubleshooting. Azure Monitor and network insights are for ongoing visibility. Defender for Cloud adds security recommendations, attack paths, and resource exploration. DDoS Protection adds attack telemetry for public IP resources.
Troubleshooting Patterns
| Symptom | Most useful tool | What it tells you |
|---|---|---|
| Traffic takes the wrong path | Next hop and effective routes | Which route Azure selected. |
| Traffic is denied | IP flow verify and effective security rules | Which NSG decision applies. |
| Intermittent app connectivity | Connection troubleshoot and packet capture | Whether connectivity is stable and where it fails. |
| Public endpoint under attack | DDoS metrics and logs | Attack telemetry and mitigation visibility. |
Scenario Workshop: Forced Tunneling Breaks Platform Access
Scenario: A workload subnet has a 0.0.0.0/0 UDR to Azure Firewall. After the route is applied, VMs cannot reach package repositories or Azure service endpoints. The security team requires all internet egress to be inspected.
The correct thought process is not to remove forced tunneling. The design requirement says inspection is mandatory. Instead, verify firewall application rules, DNS proxy behavior, route table association, and whether required Azure service FQDNs or service tags are allowed.
| Check | Why |
|---|---|
| Effective routes on VM NIC | Confirms the default route points to the firewall. |
| Firewall logs | Shows whether traffic is denied by rule or threat intelligence. |
| DNS resolution path | FQDN rules need the firewall to resolve names consistently. |
| Application rule collection priority | A deny rule can shadow a later allow rule. |
Route Precedence In Plain English
Think of Azure route selection as "most specific destination wins." A route to 10.20.1.0/24 beats a route to 10.20.0.0/16. A default route catches everything only when no more specific route exists. This is why private endpoint traffic to a specific private IP can still use VNet routing even while general internet traffic follows a firewall default route.
NAT Gateway Design Notes
- NAT Gateway is zonal or zone-redundant depending on configuration and region support.
- It applies to outbound flows from the subnet it is associated with.
- It does not provide inbound connectivity.
- It reduces SNAT port exhaustion compared to relying on default outbound access.
- It should be preferred over giving every VM a public IP for outbound-only scenarios.