Blog ENG - MS Azure - Post 4 2026
One of the most surprising behaviors I still run into with ExpressRoute is what Microsoft calls MSEE hairpinning: traffic from a VNet attached to an ExpressRoute circuit exits toward the Microsoft Enterprise Edge (MSEE) at the peering POP before it re-enters the destination VNet.
This can happen inside a single region (one circuit, multiple VNets) and across regions (multiple circuits, multiple VNets).
For years, many environments lived with it because it “worked”.
Today, the key message is different: this pattern is no longer recommended because it increases latency (you’re forcing a trip to the peering location) and it can add significant load on the ExpressRoute gateways for ingress into the destination VNet.
Why it shows up
ExpressRoute is a private connectivity model where routing is exchanged via BGP between your network and Microsoft’s edge, and VNets attach through ExpressRoute gateways.
Depending on how routes are learned and preferred, VNet-to-VNet flows may end up “preferring” the path that touches the MSEE POP rather than staying inside the Azure fabric, creating the hairpin.
The old workarounds (and why they’re discouraged)
Historically, teams tried to fight hairpinning by advertising summary routes from on-premises for intra-region traffic, or by using a cross-connected “bow-tie” approach for inter-region designs.
Microsoft explicitly flags these approaches as outdated and discourages them going forward because they don’t address the underlying latency/gateway-load downsides in a modern architecture.
What to do instead: three practical options
Option 1: transit via a hub NVA (or IP-forwarding VM) + UDRs
You place an NVA in the hub and push spoke-to-spoke traffic through it using UDRs, so packets don’t hairpin to the MSEE POP.
This can be scaled with Azure Virtual Network Manager (AVNM) for UDR distribution, and you can reduce UDR sprawl by using Azure Route Server for BGP-based propagation.
Trade-off: you gain control (and can inspect traffic), but you also own the NVA cost and operations overhead.
Option 2: VNet peering (or AVNM-managed mesh)
If you don’t need central inspection, direct peering between VNets is often the cleanest way to get the lowest latency and avoid gateway/appliance choke points.
AVNM can build and manage large-scale peering meshes, reducing manual effort when you have many spokes.
Trade-off: it’s simple and fast, but it’s not a fit when you must force all flows through a hub inspection layer.
Option 3: Azure Virtual WAN + Hub Routing Preference (HRP) tuning
Virtual WAN simplifies routing by using managed hub routing, but inter-region scenarios can still hairpin depending on topology.
If you’re effectively using a bow-tie style attachment, the article highlights setting Hub Routing Preference to AS-PATH to avoid the MSEE hairpin for inter-region flows.
Trade-off: it can reduce custom routing work, but may require redesign if you already have a traditional hub/spoke, and HRP choices can influence other routes (like VPN/SD-WAN).
Closing thoughts
My takeaway is simple: ExpressRoute is excellent for private hybrid connectivity, but it’s not automatically the best transit fabric for east-west VNet-to-VNet traffic.
If low latency matters, avoid designs that force a POP detour; pick either peering/mesh for simplicity, hub transit for inspection/control, or vWAN for managed routing with the right HRP choices.