Azure Virtual WAN: Routing Intent and Route Tables

Purpose

This guide summarises the Azure Virtual WAN concepts discussed so far and provides practical scenarios for a lab. The main area to test is custom virtual hub routing in hubs without Routing Intent.

1. Secured virtual hub and Routing Intent

A secured virtual hub contains a security provider such as Azure Firewall. Merely deploying Azure Firewall does not mean that Routing Intent is enabled.

In Azure Firewall Manager:

• Internet traffic: Azure Firewall sends Internet-bound traffic through the firewall.
• Private traffic: Azure Firewall can use either the older static-routing model or Routing Intent.
• Inter-hub: Enabled enables Routing Intent through Firewall Manager.

With Internet and Private Routing Intent enabled, Virtual WAN creates policy routes in the hub’s defaultRouteTable:

Destination	Next hop
0.0.0.0/0	Azure Firewall
10.0.0.0/8	Azure Firewall
172.16.0.0/12	Azure Firewall
192.168.0.0/16	Azure Firewall
Additional private prefixes	Azure Firewall

Routing Intent applies to all relevant connections in that hub. It does not provide a per-VNet private-traffic bypass.

For inter-hub traffic where both hubs use Private Routing Intent:

Spoke1 -> Hub1 Azure Firewall -> Hub2 Azure Firewall -> Spoke2

Both firewall policies must permit the flow, and the return path should traverse the same firewalls in reverse order.

Routing Intent restrictions

A hub using Routing Intent can have only:

• defaultRouteTable
• noneRouteTable

Custom hub route tables are not supported with Routing Intent. Selective firewall bypass therefore requires a different design, normally the static/custom-routing model.

2. Virtual hub route-table concepts

The simplest mental model is:

Association = which route table the connection reads.
Propagation = which route tables the connection publishes its prefixes into.

Association

Each connection is associated with one hub route table. Traffic arriving from that connection uses the associated table to find a route to its destination.

Propagation

A connection can propagate its prefixes into one or more hub route tables:

Connection	Prefixes propagated
VNet connection	VNet address spaces
S2S VPN	Configured or BGP-learned remote prefixes
ExpressRoute	BGP-learned circuit prefixes
P2S VPN	Client address pools

Propagation to None

Propagation to None means:

Do not dynamically install this connection’s prefixes into any usable virtual hub route table.

The connection can still consume routes from its associated route table. Other connections require an alternative route to reach it, such as:

• A static route for its exact prefix.
• An RFC1918 aggregate route through Azure Firewall or an NVA.
• Another connection mechanism outside vWAN.

Propagation to None is commonly used to prevent direct routing and force traffic through a firewall.

3. Azure VNet system routes

Azure normally creates default system routes that include:

Destination	Default next hop
VNet address space	Virtual network
10.0.0.0/8	None
172.16.0.0/12	None
192.168.0.0/16	None
0.0.0.0/0	Internet

None means discard. These RFC1918 routes are fallback routes and lose to a more-specific valid route.

Example:

10.2.0.0/16 -> vWAN hub

wins over:

10.0.0.0/8 -> None

However, 10.0.0.0/8 -> None wins over 0.0.0.0/0 because /8 is more specific than /0. Consequently, learning only an Internet default route does not automatically provide private spoke-to-spoke connectivity.

4. Routing scenarios

The following scenarios assume no NSG or firewall rule blocks the tested flow.

Scenario A: Any-to-any direct routing

VNet1: associated Default, propagates Default
VNet2: associated Default, propagates Default
S2S:   associated Default, propagates Default

The Default table learns all VNet and branch prefixes. All connections can potentially communicate bidirectionally.

Scenario B: Two VNets associated with the same table but propagating to None

VNet1: associated Custom1, propagates None
VNet2: associated Custom1, propagates None
Custom1: no applicable static routes

Sharing an association alone does not populate Custom1. Without another applicable route, neither VNet learns a path to the other.

Scenario C: One-way route knowledge

VNet1: associated Default, propagates None
VNet2: associated Custom1, propagates Default

Default learns VNet2, so VNet1 may have a forward route to VNet2. Custom1 does not learn VNet1, so the return path fails. Normal bidirectional communication does not work.

Scenario D: Internet-only central egress

VNet1: associated Default, propagates None, learns 0.0.0.0/0
VNet2: associated Default, propagates None, learns 0.0.0.0/0
Default: 0.0.0.0/0 -> Azure Firewall

Both VNets can use Azure Firewall for Internet access. If they use RFC1918 addresses and no private route exists, the built-in RFC1918 None routes normally prevent VNet-to-VNet traffic from using the less-specific 0.0.0.0/0 route.

Scenario E: Force private traffic through Azure Firewall without Routing Intent

VNet1: associated Default, propagates None
VNet2: associated Default, propagates None
S2S:   associated Default, propagates None
 
Default:
  10.0.0.0/8     -> Azure Firewall
  172.16.0.0/12  -> Azure Firewall
  192.168.0.0/16 -> Azure Firewall

The specific connection prefixes are deliberately withheld. The aggregate routes send private traffic to Azure Firewall, which inspects and forwards permitted traffic to the destination connection.

Scenario F: S2S and VNet direct routing

VNet1: associated Default, propagates Default
S2S:   associated Default, propagates Default

Default learns both the VNet and remote-site prefixes, providing routes in both directions. The on-premises router must also know that the VNet prefix is reachable through the VPN.

If the VNet propagates to None and there is no alternative static/firewall route, the hub lacks a direct return route from the S2S connection to the VNet.

5. Suggested lab

Topology

Deploy the smallest practical non-production environment:

• One Standard Virtual WAN.
• One virtual hub without Routing Intent.
• Two small VNets with non-overlapping prefixes.
• One small VM per VNet, or equivalent test endpoints.
• Optional S2S VPN connection to a test appliance or second Azure environment.
• Optional Azure Firewall, added after the direct-routing tests.

Example prefixes:

VNet1: 10.101.0.0/16
VNet2: 10.102.0.0/16
Lab branch: 10.200.0.0/16

Test sequence

1. Baseline any-to-any

   • Associate both VNets with Default.
   • Propagate both VNets to Default.
   • Confirm their prefixes appear in Default effective routes.
   • Test bidirectional connectivity.

2. Remove VNet2 propagation

   • Change VNet2 propagation to None.
   • Confirm its prefix disappears from Default effective routes.
   • Compare VNet1 NIC effective routes before and after.
   • Test both traffic directions.

3. Both VNets propagate to None

   • Confirm direct spoke routes disappear.
   • Verify that RFC1918 fallback routes use next hop None on the VM NIC.
   • Test VNet-to-VNet connectivity.

4. Custom route-table isolation

   • Create Custom1.
   • Associate both VNets with Custom1, initially propagating to None.
   • Then propagate both VNets to Custom1 and compare reachability.

5. Asymmetric propagation

   • Propagate only VNet1 to Custom1.
   • Observe which endpoint has forward route knowledge and where the return path fails.

6. Internet-only Azure Firewall

   • Add 0.0.0.0/0 -> Azure Firewall and enable Internet security.
   • Confirm Internet traffic traverses Azure Firewall.
   • Confirm the default route alone does not replace missing private routes.

7. Private inspection using static routes

   • Add RFC1918 aggregate routes to Azure Firewall.
   • Keep VNet propagation set to None.
   • Add explicit firewall rules for VNet1-to-VNet2.
   • Confirm traffic now traverses Azure Firewall.

8. Optional S2S testing

   • Test VNet and S2S propagation to Default.
   • Remove only the VNet propagation and observe the return path.
   • Add the static firewall-routing model and retest.

Evidence to capture for every test

• VNet connection association and propagation settings.
• Hub route-table configured routes.
• Hub route-table effective routes.
• VM NIC effective routes.
• Network Watcher next-hop result.
• Connection troubleshoot results where available.
• Azure Firewall network-rule logs when the firewall is present.
• Packet captures or TCP tests in both directions.

Use TCP-based tests as well as ICMP. A one-way route can allow an outbound packet to leave while the return packet fails, and ICMP may also be blocked independently by host firewalls or NSGs.

6. Useful Microsoft documentation

• About virtual hub routing
• Configure virtual hub routing