Preserve Route Server BGP communication when inserting a firewall route

Source facts

Microsoft documents that a GatewaySubnet route intended to send on-premises traffic through a firewall can also divert BGP communication between the gateway and Route Server. This occurs when the inspection route covers traffic destined for the Route Server virtual network.

The same concern applies to an SD-WAN appliance subnet peered with Route Server. Microsoft’s documented exception uses the actual RouteServerSubnet prefix with VirtualNetwork as next hop, rather than sending that control-plane path through the firewall. Microsoft Learn.

Applicability

Identify the gateway or appliance subnet, RouteServerSubnet range and proposed inspection route. Use the deployment’s actual addresses; the documentation’s example ranges are not configuration values for another network.

DSE recommendation

DSE recommends drawing the BGP path separately from the workload path during route review. Decide how the control-plane session remains reachable before associating the inspection table. Review any exception with both routing and security owners so it is neither an accidental bypass nor an omitted dependency. Retain the previous route table and the agreed recovery trigger.

Verification

During an approved test, confirm BGP adjacency and route learning as well as the intended inspected application connection. Compare the actual next hops with the reviewed paths. If workload forwarding changes while the control plane fails, stop and investigate before continuing the rollout. Record both outcomes; a successful firewall rule test alone does not establish that Route Server peering survived.

Official references

Microsoft Learn: Troubleshoot Azure Route Server issues. Source retrieved September 9, 2026.