Azure UDR's between subnet's

Question

Azure UDR's between subnet's

rr-4098 2,311

We have once vNet and setting up UDR's to route all traffic between subnet's through a third party appliance. Instead of listing all subnet that need to talk to one an other. Could I use use 0.0.0.0/0 to cover everything and force all traffic through the appliance?

0 comments

2 answers

Your answer

Answer 1

rr-4098 2,311

Thanks for the great response.. Here is what I did for routes

To-Subnet A points to appliance

TO- Subnet B points to appliance

To-Subnet C points to appliance

Then one for 0.0.0.0 points to appliance

now to be clear I do not need to create reverse routes? I assume the appliance will need to have internal routing to handle this correct?

0 comments

Answer 2

Marcin Policht 93,965 MVP Volunteer Moderator

In short, no. Azure routing relies on the Longest Prefix Match algorithm. When you create a VNet, Azure injects hidden system routes for the entire address space with a next hop of "Virtual Network". Because a system route like 10.0.0.0/16 is a more specific prefix than your user-defined route of 0.0.0.0/0, Azure would bypass your rule for internal traffic and route packets directly between subnets.

To avoid managing every individual subnet route, you can use summarized private IP blocks in your route table. By defining broader blocks that match or override your VNet space, you can capture all internal traffic. You can add the standard RFC 1918 blocks (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 ) and set their next hop to your virtual appliance. If your VNet uses a 10.x.x.x space, use your VNet address block to override the system route.

If your environment is growing, a Hub-and-Spoke topology might be a more scalable option. In this design, you place the third-party appliance in a central Hub VNet and your workloads into separate Spoke VNets. Because peered VNets cannot talk to each other transitively by default, a 0.0.0.0/0 UDR attached to the spokes should force all inter-spoke traffic through the hub appliance.

Be careful to avoid routing loops when applying these broad private range UDRs. Avoid associating this route table with the subnet that actually hosts your third-party appliance. If the appliance subnet tries to route private traffic to itself, it will create a loop and drop the packets. Keep the appliance subnet on its own distinct route table.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

rr-4098 2,311 Reputation points

2026-06-24T19:17:05.6066667+00:00

Thank you for the great response. Just to be clear I still need 0.0.0.0/0 to handle unknow \ internal traffic but for example subnets A,B,C,D,E I just need to include the CIDER address to each of them and point it to the appliance correct?
rr-4098 2,311 Reputation points

2026-06-25T18:06:36.71+00:00

I create UDR's that fit the pattern below

Subnet's A, B, C

A-to-B

A-to-C

When I create the return traffic

B-to-A

B-to-C I get the following error "The address prefix you entered matches another address prefix within this route table. Address prefixes must be unique within a route table."
Marcin Policht 93,965 Reputation points MVP Volunteer Moderator

2026-06-25T20:09:08.24+00:00
Yep - you still typically use 0.0.0.0/0 to catch Internet-bound or otherwise unknown destinations, but it will not override Azure’s more specific system routes for your internal VNet space. For east-west subnet traffic, you should add routes that specifically match your internal address ranges and point them to the virtual appliance.

However, the route table behavior is different from what you are working with. A UDR route is destination-based only. You do not create separate entries like A-to-B and B-to-A in the same route table because both routes are really just “traffic destined for subnet A” or “traffic destined for subnet B.” Azure does not track source/destination pairs in route tables.

For example, if:

Subnet A = 10.0.1.0/24

Subnet B = 10.0.2.0/24

Subnet C = 10.0.3.0/24

Then a route table associated with Subnet A would contain:

10.0.2.0/24 → Virtual Appliance

10.0.3.0/24 → Virtual Appliance

A route table associated with Subnet B would contain:

10.0.1.0/24 → Virtual Appliance

10.0.3.0/24 → Virtual Appliance

The error you are seeing occurs because Azure does not allow duplicate destination prefixes within the same route table. If you already created a route for 10.0.1.0/24, you should add another route using the same prefix even if you name it differently (A-to-B vs B-to-A). The destination CIDR must be unique per route table.

A simpler approach might be to use summarized routes. For example, if your entire VNet is 10.0.0.0/16, you can create a single route:

10.0.0.0/16 → Virtual Appliance

This should override the built-in Virtual Network route because the prefix length is identical, and user-defined routes would take precedence over system routes when the prefix match is the same. Do not associate that route table with the appliance subnet itself, or you risk creating a routing loop.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

Azure UDR's between subnet's

2 answers

Your answer