Hub and Spoke VNet Peering: ExpressRoute Default Route

I was recently working on a network design that was using a Hub and Spoke VNet Peering. The Hub network was connected to on-premises using VPN and this was transitioning to ExpressRoute. Once we transitioned to ExpressRoute we wanted to enforce a Default Route 0.0.0.0/0 back on-premises. This is done by advertising 0.0.0.0/0 to Azure Private peering through BGP and is well documented and known. What isn’t as clearly documented is how to configure Forced Tunnelling for Spoke VNets that are connected to a Hub Network.

The documentation on VNet peering talks about using User Defined Routes that can be used to direct to a virtual appliance or VPN Gateway, and traffic can flow through the appliance or VPN gateways in the Hub Network. However, if you continue reading it states that you cannot use an ExpressRoute gateway as the next hop type.

“You can deploy hub-and-spoke networks, where the hub virtual network can host infrastructure components such as a network virtual appliance or VPN gateway. All the spoke virtual networks can then peer with the hub virtual network. Traffic can flow through network virtual appliances or VPN gateways in the hub virtual network.
Virtual network peering enables the next hop in a user-defined route to be the IP address of a virtual machine in the peered virtual network, or a VPN gateway. You cannot however, route between virtual networks with a user-defined route specifying an ExpressRoute gateway as the next hop type.

It’s not clear what exactly this means, but it sounds as though you couldn’t specify a User Defined Route and use the next hop type Virtual Network Gateway if your VNet Gateway Type is an ExpressRoute gateway. This confused me, and I reached out to Microsoft to try and clarify how we could configure a Default  Route for Spoke VNets when using an ExpressRoute connected Hub network.

It turns out that the answer is actually extremely simple. When you have VNet Peering configured on the Hub and Spoke VNet, simply specifying “Allow Gateway Transit” on the Hub and “Use Remote Gateway” on the Spoke, then the Spoke VNet will also have the Default Route that is advertised to the Hub network through the private peering, unless a more specific route exists.

When the above settings are in place and you check the effective routes, you can see that the 0.0.0.0/0 route with next hop type Virtual Network Gateway is applied. Also note that the Source is “Virtual Network Gateway” and not Default or User. So it seems as though it works exactly as it is explained in the above documentation. However, you are not creating a User Defined Route that points to the ExpressRoute Gateway, it is applied by the system and works as expected.