Clarification on forcing traffic through ExR Vnet GW using UDR

Question

Hello folks, hope you're well!

I need a suggestion on forcing a specific subnet range of traffic through ExR Vnet GW using custom routes. Below are detailed explanation and supporting diagram.

Environment setup:-

We are using Spoke- Hub network topology. In our Hub Vnet we have Virtual Network Gateway (ExR Type), internal firewalls (NVAs hosted on VMSS), external firewalls (NVAs hosted on VMSS). All these three networking components are in three different subnets.

Traffic flow:-

Source:- Azure Spoke

Destination:- On-Premises

At spoke subnet, we assign a Route Table with UDR 0.0.0.0/0 --> Internal NVA. Which then picks the routes from Vnet GW, and sends the traffic to our on-premises infrastructure via ExR (refer to the Green line in infra diagram below).

Source:- Azure Spoke

Destination:- Internet (address which is not connected/ advertised to ExR)

At spoke subnet, we assign a Route Table with UDR 0.0.0.0/0 --> Internal NVA. Then, we have another route table attached to the subnet of our internal NVA with UDR 0.0.0.0/0 --> External NVA, which sends the Internet bound traffic to our External NVA for further inspection (refer to the Red line in infra diagram below)..

Issue:-

For some weird reasons one of our datacentres have chosen a non private IP address CIDR range (e.g. 104.74.243.128/28), since this DC is not directly connected to our ExR point, it is not being advertised to ExR BGP either.

Ask:- How can I force the traffic to this subnet range (109.74.243.128/28) to go to Vnet GW instead of going to External Fireewall (following the route applied to the internal firewall subnet 0.0.0.0/0 --> External NVA).

As far as I understand, I cannot create route 104.74.243.128/28 --> VirtualNetworkGateway on route table which is applied to the subnet of Internal Firewall as this is not supported for ExR type GWs (MS Doc).

Is there any other way to achieve this?

PS: We already have explored the option to NAT the traffic from our internal firewalls to on-prem but this has some other technical constraints pertaining to our environment. Hence, I'd like to explore if there are any Azure supported methods at all to force the traffic through Vnet GW --> ExR.

Infrastructure Diagram:

Thanks in advance!

Answer 1

hi & thx for sharing urs issue here at Q&A portal,

Ur understanding is right. For an ExpressRoute-type VNet gateway, u can’t use a UDR like 104.74.243.128/28 -> VirtualNetworkGateway to force that traffic into the ExR gateway. That route target works for VPN gateway scenarios, but not for forcing traffic to an ExpressRoute virtual network gateway. MS calls that out in the BGP/UDR docs. https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#border-gateway-protocol

So the supported fix is not on the Azure UDR side. The prefix needs to become a route that Azure learns from ExpressRoute BGP. If 104.74.243.128/28 is really reachable via on-prem/DC, the cleanest design is to advertise that prefix into ExpressRoute from on-prem, or summarize it from the network that does reach it.

If the DC can’t advertise it directly to ExR, then advertise it from the connected on-prem routing domain that can reach that DC. Azure doesn’t care that it’s public IP space, as long as it’s advertised over private peering and accepted by ur routing design. Just make sure u own/are allowed to route that public prefix internally. Otherwise it gets messy fast.

If advertising the prefix over ExR is not possible, then ur Internal NVA needs to make the forwarding decision itself. Meaning: add a route on the Internal Firewall/NVA for 104.74.243.128/28 toward the on-prem/ExR path, not toward the External NVA default route. In practice that may mean routing via the internal firewall’s next hop design, BGP with the NVA, or another NVA-side policy route. Azure route table alone won’t push it into the ExR gateway.

Another option is NAT/translation, but u already said that has constraints. Still, from an Azure-supported design view, the options are basically: advertise the prefix over ExR, route it inside the NVA layer, or redesign the path.

no supported Azure UDR trick to force a non-advertised prefix into an ExR VNet gateway. Get the prefix into ExR BGP, or make the Internal NVA handle that exception route before it follows the 0.0.0.0/0 -> External NVA path.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/