Robert Mahon

Azure Bastion vs UDR

Intro

In this blog post, I want to talk about use of Azure Bastion and UDR (route tables) and how to be careful when intra-subnetting in a hub-spoke network topology.

The Design

Let’s set the stage in terms of the network architecture design to give some context and a understanding.

  • It’s a hub-spoke network design
  • The hub that will act as the perimeter for connections inbound and outbound.
  • The spokes is where my compute will reside for example VM’s.
  • Peering in place between hub and spokes.

Before showing the design, I am going to throw a little curve ball into a mix and place a shared services subnet for a DC in the Hub! Some people might have a problem with this in the first place and question why have you compute in the hub!? 🤯

However, this a use case scenario where there is compute in the hub so please don’t judge me yet 😅

Now that you have the high level network design, lets get stuck into the routing requirements. I want to achieve intra-subnetting meaning route all my traffic leaving a subnet to go to Azure Firewall for allow/deny, filtering etc…

Example – I want my VM in the spoke VNet to communicate with the DC in the hub VNet for auth services but Azure Firewall rules will be required to allow this traffic.

The Configuration

So if I want to force tunnel all the traffic back to Azure Firewall, I will require a Route Table (UDR). Create my route table and away I go! Very straight forward process.

First thing usually is, I will route all the 0.0.0.0/0 traffic to the Azure Firewall.

Next, I want my VMs in the spokes to talk to the DC that is in shared services subnet in the hub but remember Azure Firewall has to allow it.

Now, if there is more than just a DC in the hub and there is more compute you need to connect to, you would think the easiest solution would be to provide the whole VNet address space 10.100.0.0/22 in the route table so its applicable to all subnets… Wrong!

Oh no!! I cant Bastion onto any of my VM’s in the spokes VNet’s 🤔


The Problem

The issue in this instance is, I have overridden the default VNet peering route with trying to route all destined traffic for 10.100.0.0/22 to Azure Firewall.

When I look at the effective routes, you can see that the state of the default route is invalid for the VNet peering. Not good!

What does this mean for Bastion? It means I have overridden the Bastion route too and I don’t have a route to my VM using Bastion.

Unfortunately, Azure Bastion doesn’t support UDR meaning I can’t access VMs behind Azure Firewall with Bastion so I can’t manipulate the routing for Bastion to hit Azure Firewall for allow/deny – For reference – https://learn.microsoft.com/en-us/azure/bastion/bastion-faq#udr

The Correct Configuration

The correct configuration to make in this instance is to use the longest prefix match on my route table. So, if I have to get back to the Shared Services subnet, I must define the subnet address space (10.100.0.0/26) and NOT the VNet address space (10.100.0.0/22)

Looking at my effective routes, it looks much healthier as I am not overriding the VNet peering route.

This also means that I am not messing up the routes for Bastion 😎

What does this look like in my hub-spoke network design including the routes? As you can see below, I am using the longest prefix match where applicable.

The Conclusion

My conclusion to this type of configuration is to be very careful when intra-subnetting in a hub-spoke topology.

  • It requires an understanding of both default and the user defined routing.
  • Making sure to use longest prefixes matches where required on route tables.

What would help, is the ability to attach UDR to the Bastion subnet and access VM’s behind Azure Firewall or an NVA with Bastion.

However, I would have a different outlook on intra-subnetting in Azure and Product teams may have the same. Here’s why..

  • Subnet-subnet traffic is private traffic in Azure whether its within a VNet or over VNet peering.
  • Bastion access to VM’s is private traffic too.

So why mess around with it? Why not trust that private traffic? Why not keep your routing simple where applicable in a hub-spoke topology? There will be pros and cons to both sides of the argument with intra-subnetting but my preference is – Keep It Simple!!

I hope you liked this post, please feel free to provide feedback and any questions don’t hesitate to ask! Thanks ✌

Leave a comment