# Keep ExpressRoute circuit-to-circuit transit out of a Route Server design

> Check the documented route-exchange boundary before expecting two circuits to communicate.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-194-keep-expressroute-circuit-to-circuit-transit-out-of-a-route-server-design/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:31:46+00:00
- Modified: 2026-09-17T16:46:30+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 1 minutes

## What you need to know

Check the documented route-exchange boundary before expecting two circuits to communicate.

## Potentially affected

Apply this boundary when designing transit between locations attached through separate ExpressRoute circuits. Identify each circuit, gateway and required destination. Do not infer circuit-to-circuit support from Route Server's documented exchange with VPN gateways or NVAs.

## DSE recommendation

DSE recommends marking the required transit path explicitly in the architecture before enabling route exchange.

## Article

## Source facts

Microsoft explicitly excludes ExpressRoute circuit-to-circuit connectivity through Azure Route Server. Routes from one circuit are not advertised to another circuit connected to the same virtual network gateway. The guidance points to ExpressRoute Global Reach for consideration when ExpressRoute-to-ExpressRoute connectivity is required. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/route-server/expressroute-vpn-support).

## Applicability

Apply this boundary when designing transit between locations attached through separate ExpressRoute circuits. Identify each circuit, gateway and required destination. Do not infer circuit-to-circuit support from Route Server’s documented exchange with VPN gateways or NVAs.

## DSE recommendation

DSE recommends marking the required transit path explicitly in the architecture before enabling route exchange. If the requirement crosses the excluded boundary, have the network owner assess an appropriate alternative and its own prerequisites. Keep that assessment separate from granting more permissions or changing BGP filters on a design that does not support the intended exchange.

## Verification

Review the actual topology and advertised routes against the chosen design. Test the approved transit path only after its prerequisites and routing controls are established. Preserve the path identity and application observations in the acceptance record. If expected prefixes are absent, check the documented boundary before treating their absence as a Route Server malfunction.

## Official references

[Microsoft Learn: Azure Route Server support for ExpressRoute and Azure VPN](https://learn.microsoft.com/en-us/azure/route-server/expressroute-vpn-support).

## Primary reference

- Name: Azure Route Server support for ExpressRoute and Azure VPN - Azure Route Server | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/route-server/expressroute-vpn-support
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Keep ExpressRoute circuit-to-circuit transit out of a Route Server design,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-194-keep-expressroute-circuit-to-circuit-transit-out-of-a-route-server-design/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.