In this post, I want to explain how a new preview feature in Azure networking, called Disable VNet Peering Route, will simplify Azure networking and improve site-to-site security in a hub-and-spoke network.
The Problem
Imagine a hub-and-spoke network implementation in Azure. Each spoke is peered with the hub; as a result, the Azure fabric generates a system route for each spoke VNet in the hub. Each system route states that any packet travelling to a spoke address will go directly from the source NIC in the hub to the destination NIC in the spoke.
The hub has a firewall. All spoke subnets have a Route Table with a User-Defined Route (UDR). The UDR forces all traffic leaving the spoke VNet to use the firewall as the next hop. Perfect. But we have a hole …
Now we will add site-to-site networking, which could be an appliance(s) that include:
- VPN Virtual Network Gateway
- ExpressRoute Virtual Network Gateway
- Third-party site-to-site networking appliance, such as SD-WAN
Under the covers, each of the above is 1+ VMs with a NIC each. When a packet comes in over site-to-site networking, it will leave the VM and attempt to reach the destination address in a spoke. What route will it take? By default, the packet will go directly to the destination, bypassing the firewall in the hub. We end up with insecure site-to-site networking and asynchronous routing, which breaks connection-oriented traffic.
The fix is to add a UDR to the subnet of the site-to-site networking appliance. For each spoke prefix, you add a route. The route is: to get to PrefixA, the next hop is the private IP address of the hub firewall. The firewall controls/filters/inspects the ingress packets, and becomes a router, to re-transmit the traffic based on the system routes that were generated by peering.
Aidan, we have 100 spokes. That’s 100 UDRs that we have to add to the GatewaySubnet. That’s a lot of work and maintenance. Can we have 1 summary route instead, saying that all traffic to 10.100.0.0/16 can go via the firewall? Nope, because the system route for the spokes still exist. Longest Prefix Match will kick in and prefer the system route, continuing to send the traffic directly to the destination and bypass your firewall.
My Fix
For the longest time in my old job, we had each spoke generate a UDR in the hub GatewaySubnet using ARM/Terraform. There was a bug in that approach – an update of the hub Route Table would erase the UDRs and lead to asynchronous routing. We had the other sneaky problem, which was a new spoke that didn’t add a UDR would have asynchronous routing issues too.
In my company, Cloud Mechnaix, I created an Azure Automation solution that uses the Automation Account’s service principal to run a script. The script scans the hub’s peering configurations, gets the prefix(es) of each spoke, and ensures that a UDR is created for each. That process runs every 15 minutes, ensuring that the necessary UDRs are in place within 15 minutes of a new spoke VNet being added. The whole thing is configurable using a master control file, including networks to exclude, subnetsto manage, additional routes to include, and so on. It works. My original plan was to share this solution on GitHub … but then I learned that something was coming.
Disable VNet Peering Route
I opened my Azure news source (The Azure Daily) this morning to see a new announcement. Microsoft has launched a preview of a new feature where we can disable the creation of a system route that is generated by peering two VNets. This is controlled using a Route Table, on the subnet where the system routes would be generated.
Let’s get back to the question that “you” asked me: Aidan, we have 100 spokes. That’s 100 UDRs that we have to add to the GatewaySubnet. That’s a lot of work and maintenance. Can we have 1 summary route instead, saying that all traffic to 10.100.0.0/16 can go via the firewall? Yes!
Step1: You enable Disable VNet Peering Route on the Route Table of the GatewaySubnet. Note that you do not enable this feature on the firewall subnet or the Bastion subnet because they must still have system routes to reach the spoke subnets. This stops the generation of system routes in the GatewaySubnet.
Step 2: You can create a “summary route(s)” that includes all of your potential spokes. No system routes exist and Longest Prefix Match will not alter the traffic.
Let’s say that all my spokes are/will be in 10.100.0.0/16. Now I can create 1 single UDR for all spokes:10.100.0.0/16 via Firewall private IP address
Read Before Continuing
Hold on to those horses. This is a preview and there are restrictions.
- The Azure Firewall or NVA next hop must be in the same virtual network as the source workload’s network interface. A next hop in a peered virtual network isn’t supported.
- Peering route suppression doesn’t apply to Azure BareMetal Infrastructure workloads. BareMetal workloads in a subnet associated with a route table that uses this feature continue to use standard longest-prefix-match routing and don’t use the summarized routes for this feature. Other supported workloads in the same subnet use the summarized routes normally.
- For Terraform, use the AzAPI provider. The AzureRM provider doesn’t currently support this setting.
Opinion
I’ve wanted this feature since the very first time I figured out how routing really works in Azure. I begged for it. I gave up asking for it years ago. I was delighted to learn about it because this feature:
- Simplifies networking.
- Removes a common mistake/misunderstanding that leads to broken or insecure workloads.
Thanks Azure Networking!