Clarification on RFC1918 Route Advertisement Requirements with Azure Virtual WAN Routing Intent

Question

We are seeking clarification regarding the route advertisement requirements when using Azure Virtual WAN with Routing Intent enabled.

Our current on-premises environment advertises the entire RFC1918 address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) over BGP. We have established a Site-to-Site VPN connection between our on-premises environment and Azure Virtual WAN, with Routing Intent configured to route traffic through Azure Firewall.

Based on Microsoft's documentation, we understand that when Routing Intent is enabled, the on-premises environment should advertise only the specific prefixes that exist on-premises rather than the entire RFC1918 ranges.

To validate this behavior, we built a proof of concept. We observed that Azure advertises only the specific VNet CIDR prefixes over BGP to the on-premises environment and does not advertise the entire RFC1918 ranges, which aligns with the documented behavior.

However, we would like clarification on the following points:

1. If our on-premises environment continues to advertise the entire RFC1918 ranges to Azure Virtual WAN while Routing Intent is enabled, what are the potential impacts? Specifically:
   • Will this cause routing issues, asymmetric routing, or traffic blackholing?
   • Does Azure reject or ignore these advertisements, or are they accepted with limitations?
   • Are there any scenarios where advertising the full RFC1918 ranges could interfere with Routing Intent or Azure Firewall behavior?
2. Microsoft recommends advertising only the specific on-premises prefixes instead of the entire RFC1918 ranges. Could you explain the underlying reason for this recommendation? What routing problem or design consideration does advertising more specific routes address?
3. If we replace the RFC1918 advertisements with only the actual on-premises network prefixes, how does Azure Virtual WAN process these routes differently, and how does this improve the routing behavior compared to advertising the aggregate RFC1918 ranges?

Answer 1

Hello Ankit Mukherjee,

Greetings! Thanks for raising this question in the Q&A forum

This is a very well framed question, and I was able to trace the exact mechanism through the official Virtual WAN routing documentation. The short version is that your PoC observation is correct, and the reason Microsoft recommends advertising only your actual on-premises prefixes rather than the full RFC1918 aggregates comes down to how the virtual hub resolves route ties when prefix lengths are equal.

Here is the mechanism, piece by piece.

How Routing Intent builds the private routing path

When Routing Intent is enabled with a private routing policy, Virtual WAN automatically injects static routes for the RFC1918 aggregates, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, into the defaultRouteTable, with Azure Firewall as the next hop. This is the catch-all path meant to force any private traffic that doesn't have a more specific match through the firewall for inspection.

How the virtual hub picks a route when there are multiple candidates

The hub's route selection algorithm runs in this order, Longest Prefix Match first, then static routes over BGP routes as a tiebreaker when prefix lengths are equal, then the configured hub routing preference (ExpressRoute, VPN, or AS Path) for any remaining ties.

What happens if on-premises also advertises the full RFC1918 aggregates

To answer your first question directly, Azure does not reject these advertisements outright. The restriction that blocks RFC1918 prefixes applies specifically to ExpressRoute Microsoft peering, not to private peering or Site-to-site VPN, so your on-premises router's 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 advertisements are accepted into the hub's BGP table as valid routes. The risk appears when the prefix length of what on-premises advertises exactly matches the prefix length of the platform's own injected private_traffic static route. Since static routes are preferred over BGP routes at equal prefix length, the platform's own aggregate route to Azure Firewall wins that tie, not your on-premises BGP advertisement. If your on-premises environment only advertises the blanket RFC1918 ranges without also advertising the specific subnets that actually exist on-premises, traffic destined for those legitimate on-premises subnets can end up routed to Azure Firewall instead of toward your VPN tunnel, since nothing more specific exists to win on Longest Prefix Match. Depending on your firewall rules, this can present as traffic being silently dropped or blackholed rather than an obvious failure, which is the asymmetric routing risk you asked about.

Why advertising only the specific on-premises prefixes fixes this

This is the answer to your second and third questions together. When you advertise your actual on-premises subnets, for example 10.20.0.0/16 rather than the full 10.0.0.0/8, that advertised prefix is strictly longer than the platform's injected /8 aggregate. Longest Prefix Match is evaluated before the static versus BGP tiebreaker, so your specific on-premises route always wins for traffic actually destined to your real subnets, regardless of the static route preference rule. Everything else within the RFC1918 space that isn't covered by one of your specific advertisements correctly falls through to the platform's aggregate static route and gets sent to Azure Firewall as intended. This is exactly the behavior Routing Intent is designed around, specific known destinations take precedence, and anything undefined or unexpected is caught and inspected by the firewall rather than silently trusted to on-premises.

Recommended verification step

You can confirm the actual selected next hop for a given prefix directly rather than relying on the BGP table alone, since BGP table entries do not tell you which route the hub actually selected after the LPM and static-versus-BGP evaluation.

Portal path: Virtual WAN hub > Effective Routes > select the defaultRouteTable, then query a specific on-premises prefix to see the selected next hop

az network vhub get-effective-routes \
  --resource-group <rg-name> \
  --name <hub-name> \
  --resource-type RouteTable \
  --resource-id <defaultRouteTable-resource-id>

If you want to validate this in a controlled way before changing your production on-premises advertisements, I'd suggest testing in a lab hub with routing intent enabled, advertise only the RFC1918 aggregates without the specific subnet, and confirm via Effective Routes that traffic to a real on-premises test subnet resolves to Azure Firewall rather than the VPN connection. That will give you concrete proof for your own change documentation.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.