The Issue with Azure Bastion in Virtual WAN

Intro

Most people have used Azure Bastion before. The uptake of the ease-of-use product has been great, and for years it’s been simple and effective. However, as more and more people move to Virtual WAN (vWAN), the experience hasn’t been so great.

For those that haven’t used it before, Azure Bastion is a resource that allows users to initiate an RDP-like connection over HTTPS to servers within Azure without the need to open ports, add public IP addresses, or compromise security. It is secured by EntraID in the first case, and a username/password is still required to authenticate to the VM.

Out of the box, deploying Bastion into a virtual network (VNet) within Azure should give you the ability to connect to any virtual machine by simply hitting connect and providing a username/password.

But when deployed into vWAN, this doesn’t work, and Bastion can only reach virtual machines within its current VNet. This leaves you at a crossroads: do I deploy one per VNet (incurring duplications of cost), do I scrap Bastion and go for something else, or do I find a solution?

Why Doesn’t Bastion Work in the Typical Way with vWAN?

In the ‘hub and spoke’ model, widely used, Bastion is deployed within a VNet and can provide seamless access to VMs using private IP addresses or directly by resolving the Azure side DNS name for the VM. However, in vWAN, things work differently:

• vWAN interconnects VNets through a Virtual WAN Hub (vWAN hub) controlling regional and global routing.
• Bastion will only be able to route to virtual machines within its own VNet. This could be a tempting solution, but at £170.25 for Standard in UK South per instance, this could very quickly get expensive!
• Inbound client connections reach Bastion directly, while outbound traffic traverses the firewall, causing asymmetric routing and dropping any successful connections.

As a result, using Bastion in vWAN will not work across VNets similar to that seen in hub and spoke or mesh networks.

So How Can We Use Bastion in vWAN?

If you’ve got this far and still feel inclined to stick with Bastion but don’t want a resource per VNet, fear not, there is a solution!

1. Deploy a VNet specifically for Bastion - As Bastion will be the only service, we want to ignore the default routes provided by the vWAN Hub. It makes sense to prevent that nothing else takes this path.
2. Ensure that an NSG has been created for the AzureBastionSubnet - This NSG should allow the connections inbound and outbound. Working with VMs and NSGs in Azure Bastion
3. Disable default route propagation for the new Bastion VNet - Ensure that inbound/outbound traffic takes the same route.
4. Create a firewall rule to allow Bastion to reach other VNets - Source: ‘Bastion VNet’, Destination: ‘Regional Range’, Destination ports: ‘22, 3389’.

Limitations & Considerations

While this approach allows Bastion to work within vWAN, there are a few things to keep in mind:

• Manual IP Input - Since private DNS resolution doesn’t work in the same way, users must manually enter IP addresses rather than directly clicking on.
• Regional Availability - Ensure Bastion is deployed in the same region as the VNets that need access.

Final Thoughts

Whilst Bastion does not work traditionally in a Virtual WAN environment, it can still be used by connecting via private IP addresses instead of relying on private endpoints. To avoid connectivity issues, deploy Bastion in a dedicated VNet and disable default route propagation to prevent asymmetric routing.

Are you using Bastion with vWAN? What challenges have you faced, and how have you worked around them? Let’s discuss in the comments! 🚀

Note: This issue is documented on Microsoft’s Bastion FAQ though the information is fairly limited.