Episode #1: VNET connectivity, impact of Virtual Network Gateways, On-Prem route propagation options
Introduction note: This guide aims at providing a better understanding of the Azure routing mechanisms and how they translate from On-Prem networking. The focus will be on private routing in Hub & Spoke topologies. For clarity, network security and resiliency best practices as well as internet breakout considerations have been left out of this guide.
1.1. Discovery/Reminder of Azure VNET connectivity principles
1.1.1. VNET peering & Effective routes
1.1.2. Standard Hub & Spoke topology and non-transitivity of VNET peerings
1.2. Connectivity impact of adding a Virtual Network Gateway (ER or VPN)
1.2.1. Azure Virtual Network GW (VPN or ER) for On-Prem connectivity
1.2.2. On-Prem <=> Spoke VNET propagation (Gateway Transit & Gateway route propagation features)
To start, we will consider 2 peered VNETs and a VM in Spoke1 VNET. A single IP range* is allocated to each VNET. In the example below, each IP range is broken into 2 subnets.
* An Azure Virtual Network (VNET) is made of one or multiple IP ranges and each range is split into subnets.
From an Azure networking perspective, according to Spoke1VM's Effective routes, Spoke1VM will know about the overall range of its own VNET (but won’t have the granularity of the more specific subnets) and the range of any other peered VNET.
By default all resources in a VNET can communicate outbound to the internet, hence the default route.
Peering connections are non-transitive: in a standard Hub & Spoke topology like depicted below, Spoke1VM will know about the Spoke1 VNET range AND the central VNET (Hub VNET) range, but because there is no direct peering between Spoke1 VNET and Spoke2 VNET, they won’t know about each other.
Using this peering logic, since the Hub VNET is peered with both Spoke1 and Spoke2 VNETs, the HubTestVM will know about its own Hub VNET range and both Spoke1 & Spoke2 ranges.
Let's look at the default route propagation when an Virtual Network GW is deployed (Expressroute GW here, but the results would be similar with a VPN GW).
The Virtual Network GW is usually hosted in a central Hub VNET, and must be in the Gatewaysubnet subnet.
➡️ Whether it is VPN or ER, if a Virtual Network Gateway (VNG) is added in a Hub VNET and further connected to On-Prem, the On-Prem prefixes received by the virtual Network GW will by default automatically be known within this Hub VNET. The Hub VNET range is advertised in return to the On-Prem.
➡️ By default, the On-Prem connectivity is not extended over existing VNET peerings: the On-Prem prefixes received by the Virtual Network GW are NOT readvertised to the peered Spoke VNETs and the Spoke VNET IP ranges are NOT propagated On-Prem.
The On-Prem is emulated by a VNET connected to the Hub VNET Expressroute circuit.
1.2.2.1. “Gateway transit” scope = the entire VNET & the VNET range is (or is not) advertised On-Prem
Gateway Transit allows to extend the scope of the connectivity between Azure and the On-Prem to peered VNETs, as represented on the diagram below for Spoke1 VNET.
It is a per-VNET peering feature that must be applied on both ends of a peering:
➡️ The On-Prem prefixes will start being “treated” like IP ranges of the Hub VNET: following the VNET peering principle they will get propagated to this directly peered Spoke VNET and be programmed in its VMs, with Virtual Network Gateway displayed as Next-Hop type.
➡️ And in return, the Spoke1 VNET range will also be advertised On-Prem.
1.2.2.2. “Propagate Gateway Routes” scope = selected subnets of a VNET only & the VNET range still gets advertised On-Prem
Spoke1VM2 is a new VM is added in Spoke1/subnet2. As GW Transit is enabled for Spoke1, Spoke1VM2 does know about the On-Prem prefixes. But let's imagine we want the resources in this specific subnet to be isolated from On-Prem.
➡️ If a route table with Gateway route propagation = disabled is applied to a specific subnet, either in the VNET hosting the Virtual Network Gateway or in a peered VNET, then the On-Prem prefixes received by the GW will NOT be propagated to this given subnet.
➡️ When GW route propagation is disabled, even on all the subnets of a VNET, the overall VNET IP range is STILL propagated On-Prem.
