You’ve pointed a summary route at the firewall, but traffic to a peered spoke still goes directly to the destination. Check the prefixes: a more-specific system peering route can beat your user-defined route (UDR).

For engineers operating hub-and-spoke inspection, disable peering route propagation (preview) offers a way to remove those competing peering routes instead of maintaining an override for every spoke. The useful outcome is less repeated route maintenance while keeping selected traffic on the inspection path.

There is one eligibility check to make before trying it: during preview, the firewall or network virtual appliance (NVA) next hop must be in the same VNet as the source workload NIC. A workload in the hub can meet that rule with a hub appliance. If your main problem is steering spoke-originated traffic through a firewall located only in the peered hub, this preview doesn’t currently solve it. That is a restriction of this preview feature, not a prohibition on ordinary UDR service chaining.

The Mental Model

Peering provides connectivity; routes determine which next hop a packet uses. This setting removes system-generated peering routes for supported workloads on the subnets associated with a route table. Your UDRs still have to supply the intended path.

Consider this illustrative hub-side workload, with the appliance in the same VNet and two peered spokes:

Before suppression, traffic to 10.20.1.10 follows the /16 peering route, not the /15 UDR. Longest prefix match comes first; being user-defined doesn’t make a broader route win. After suppression, those peering routes are removed from consideration, allowing the summary UDR to select the appliance, assuming no other winning route exists.

That’s the change: remove the competing automatic routes, not change Azure’s route-precedence rules.

You can already override those system routes with matching-prefix UDRs: at an equal prefix length, a UDR takes precedence over a system peering route. This preview doesn’t introduce inspection as a new capability. It exchanges repeated per-peer route configuration for responsibility for every required peering path affected by suppression. Less route maintenance, more responsibility for route completeness is the trade-off.

Peering stays configured. Whether traffic still gets through depends on the replacement routes and the appliance path.

How It Really Works

The control lives on the route table as disablePeeringRoute. By default, None keeps system-generated peering routes; set it to All to suppress generated IPv4 and IPv6 peering routes for supported workloads on associated subnets.

The scope is easy to misread: it’s a route-table setting, not a switch on each peering connection. Every associated subnet inherits it for supported workloads. It doesn’t let you suppress just one chosen peer. Use separate tables when subnet routing policies differ.

Before configuration, register the Microsoft.Network/AllowDisablePeeringRoutes preview feature in the subscription that contains the route table. The setting is available through the Azure portal, CLI, and PowerShell; REST, ARM, and Bicep deployments need route-table API version 2025-07-01 or later.

For PowerShell, use Az.Network 8.1.0 or later. Sign in, select the subscription that owns the route table, and request preview registration once:

1
2
3
4
5
6
7

Connect-AzAccount -ErrorAction Stop
Set-AzContext -SubscriptionId "<subscription-id>" -ErrorAction Stop

Register-AzProviderFeature `
  -FeatureName AllowDisablePeeringRoutes `
  -ProviderNamespace Microsoft.Network `
  -ErrorAction Stop

Registration may take time. Run the following check again later if it isn’t ready; there’s no need to repeat the registration request. Refresh the network provider only after the feature reports Registered:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

$feature = Get-AzProviderFeature `
  -FeatureName AllowDisablePeeringRoutes `
  -ProviderNamespace Microsoft.Network `
  -ErrorAction Stop

if ($feature.RegistrationState -ne "Registered") {
  throw "Preview feature state is '$($feature.RegistrationState)'. Wait for Registered, then run this block again."
}

Register-AzResourceProvider -ProviderNamespace Microsoft.Network -ErrorAction Stop

The next example assumes the route table already exists and is associated with the source subnet. Choose a destination prefix that matches only traffic intended for inspection, and use an appliance private IP in the same VNet as the source workload NIC. It adds the UDR and enables peering-route suppression together:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

$resourceGroup = "<resource-group>"
$routeTableName = "<route-table-name>"
$routeName = "inspect-spoke-ranges"
$destinationPrefix = "<summarized-spoke-prefix>"
$appliancePrivateIp = "<nva-private-ip>"

$routeTable = Get-AzRouteTable `
  -ResourceGroupName $resourceGroup `
  -Name $routeTableName `
  -ErrorAction Stop

if ($routeTable.Routes.Name -contains $routeName) {
  throw "Route '$routeName' already exists. Review or update it explicitly before continuing."
}

$routeTable = Add-AzRouteConfig `
  -Name $routeName `
  -AddressPrefix $destinationPrefix `
  -NextHopType VirtualAppliance `
  -NextHopIpAddress $appliancePrivateIp `
  -RouteTable $routeTable `
  -ErrorAction Stop

$routeTable.DisablePeeringRoute = "All"
Set-AzRouteTable -RouteTable $routeTable -ErrorAction Stop

$updatedRouteTable = Get-AzRouteTable `
  -ResourceGroupName $resourceGroup `
  -Name $routeTableName `
  -ErrorAction Stop

$updatedRouteTable.DisablePeeringRoute
$updatedRouteTable.Routes |
  Where-Object Name -eq $routeName |
  Select-Object Name, AddressPrefix, NextHopType, NextHopIpAddress

This is a documented configuration example, not a report of an executed Azure test. It leaves existing routes and subnet associations in place; it doesn’t configure the appliance or its onward path. The final output confirms saved configuration, not effective forwarding. Review the existing routes and all associated subnets before applying it; pause other writers to the table while making the change.

To restore peering-route propagation, retrieve the table again, set DisablePeeringRoute to "None", and save it with Set-AzRouteTable. That alone isn’t a full rollback: the added UDR remains, and existing overrides still affect route selection. Preserve the original configuration and restore the routes your change plan requires.

Real-World Impact

The best fit is a growing hub-and-spoke network where eligible source subnets need the same inspection path to multiple spokes. Microsoft’s overview describes using suppression with a summary UDR to avoid maintaining an override for every peer. The day-to-day benefit is fewer route edits when another spoke joins that same routing policy.

A more manageable hub-and-spoke route table

Take a shared-service workload in the hub that contacts applications in the two spokes from the earlier example. Both destinations require inspection by the hub appliance. Without suppression, you might maintain /16 UDR overrides to beat the matching system peering routes. With suppression on the source subnet’s route table, the /15 summary can express that shared intent.

The appliance must still forward traffic over peering to the destination. Don’t apply the source subnet’s suppression policy blindly to the appliance subnet: removing the appliance’s onward routes or sending it back to itself can break the path you’re trying to build.

For a stateful inspection design, the spoke’s response to the hub workload must also traverse the intended appliance path. The spoke may need a matching-prefix UDR for that return destination to override its direct peering route; changing the hub source table doesn’t configure this return route. The example shows the outbound route-selection change, not a complete bidirectional deployment.

When I would keep explicit routes

Suppose the next spoke needs a different appliance or must bypass this inspection path. Don’t widen the summary just to keep the table short. Keep its route explicit and review the remaining effective routes before enabling suppression for that source subnet.

My recommendation is to use this where the routing intent is genuinely repetitive and the address plan makes summarization safe. If every spoke needs an exception, a smaller table isn’t worth making the packet path harder to explain. This feature controls route propagation; it doesn’t centralize firewall management or replace destination-specific policy.

Gotchas and Edge Cases

The outage pattern is deceptively quiet: peering still shows connected, but an application times out because its old system route is gone and its replacement UDR is missing, wrong, or points to an appliance that cannot forward the flow. A healthy peering status does not validate the new path.

Suppression covers more than the summary

All suppresses generated IPv4 and IPv6 peering routes, not just the destinations covered by your new UDR. Inventory every peer and required destination first. One IPv4 summary won’t replace other IPv4 paths or any IPv6 paths you still need.

Route selection isn’t end-to-end inspection

Other routes can still win. This property doesn’t disable BGP route propagation, and it doesn’t remove existing UDRs. Check the effective route for each test destination rather than assuming suppression makes the summary authoritative.

Forwarding, firewall policy, NSGs, peering settings for forwarded traffic, and the return path are separate work. For a custom NVA, verify IP forwarding at the Azure NIC and appliance/OS layers. With a stateful firewall, asymmetric return traffic can break an otherwise plausible outbound design.

Preview workload and tooling exclusions

Azure BareMetal Infrastructure workloads aren’t covered: they retain standard longest-prefix-match behavior even when sharing a subnet with supported workloads. Terraform currently requires the AzAPI provider rather than AzureRM. Manage this preview setting on the route table, not through Azure Virtual Network Manager routing rule collections. Behavior and availability may change; check the current documentation before deployment.

Best Practices

Start with a dedicated canary source subnet and route table, not a table shared across production. Capture the original configuration and effective routes, then record a small test matrix: source NIC, destination IP, protocol/port, expected next hop, and expected application result. Include both inspected destinations and destinations outside the summary.

After applying the change, check three things:

1. Route selection: generated peering routes are suppressed for the supported source NIC, and the intended UDR selects the appliance for each inspected destination. Required paths outside the summary still have the correct route.
2. Actual traffic: bidirectional application tests succeed, and appliance telemetry shows the tested flows being processed. A successful connection alone doesn’t prove inspection; effective routes alone don’t prove packet delivery.
3. Maintenance reduction: compare the routes before and after. Retire redundant per-spoke overrides only after validating the replacement path; the PowerShell example deliberately doesn’t delete them.

If a required flow fails or takes an unexpected path, stop expansion and restore the captured route configuration, including the suppression setting. Agree on who performs that rollback before the change window. Repeat the checks when adding peers, changing address ranges, or introducing route exceptions.

Learn More

• Configure disable peering route propagation
• Azure Virtual Network Peering: disable peering route propagation (preview)
• User-defined routes overview
• Diagnose a virtual machine routing problem