# Making a summarised UDR take precedence: disable peering route propagation

## Intro

When operating a hub-and-spoke Azure platform, we usually need to maintain routing on the GatewaySubnet for each new spoke to ensure return traffic travels through the firewall. For other subnets, a default route (0.0.0.0/0) with next hop to the virtual appliance handles this — but that doesn’t work for the GatewaySubnet. Azure uses longest prefix match, meaning the most specific route takes precedence, so a broad route on the GatewaySubnet loses to the more specific system peering routes. Microsoft recently announced a preview setting to disable peering route propagation, ultimately removing this task for the operations team.

## Why this problem exists

Azure automatically adds system routes to the GatewaySubnet for each peered spoke VNet’s address space. Because these are more specific than a summarised UDR and as mentioned Azure uses longest-prefix match, and return traffic goes straight to the spoke, skipping the firewall. To force it through the firewall, you add a per-spoke override that’s more specific on the GatewaySubnet route table.

## The feature: disablePeeringRoute

Now in public preview, you can disable peering route propagation. It suppresses the system peering routes on subnets using that route table, but doesn't alter the peering connections. The property `disablePeeringRoute` is set on the route table. With the peering routes suppressed, the summarised UDR on the GatewaySubnet takes precedence, and the per-spoke override is no longer needed.

## Azapi configuration

```hcl
resource "azapi_resource" "gateway_route_table" {
  type      = "Microsoft.Network/routeTables@2026-03-01" # must be >= 2025-07-01 for disablePeeringRoute
  name      = "rt-hub-gatewaysubnet"
  parent_id = azapi_resource.resourceGroup.id
  location  = var.location

  body = {
    properties = {
      disablePeeringRoute        = "All"   # suppresses system peering routes so the summarised UDR wins
      disableBgpRoutePropagation = false
      routes = [
        {
          name = "to-spokes-via-firewall"
          properties = {
            addressPrefix    = "10.0.0.0/8"   # summarised spoke range
            nextHopType      = "VirtualAppliance"
            nextHopIpAddress = "10.0.1.4"      # Azure Firewall private IP
          }
        }
      ]
    }
  }

  schema_validation_enabled = false
  response_export_values    = ["*"]
}
```

## Caveats

Preview features usually arrive with limitations and generally aren’t advised for production. Other than that there are a few caveats to consider:

- Next hop must be in the same VNet as the source NIC. For the `GatewaySubnet` case, that means the gateway and the firewall or NVA sit in the same VNet — which they do in a standard hub.
- azapi supports it, azurerm doesn’t yet. You also need API version 2025-07-01 or later for the property to exist.
- Have your UDR in place before you enable this — it creates no replacement routes, so suppressing the peering routes without a working UDR will black-hole traffic.

## References

- [Disable peering route propagation (preview) — Virtual network peering overview](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview#disable-peering-route-propagation-preview)
- [Microsoft.Network/routeTables (2025-07-01) — AzAPI/Terraform reference](https://learn.microsoft.com/en-us/azure/templates/microsoft.network/2025-07-01/routetables?pivots=deployment-language-terraform#routetablepropertiesformat)
- [Microsoft.Network/routeTables change log](https://learn.microsoft.com/en-us/azure/templates/microsoft.network/change-log/routetables)