The Issue with Azure Bastion in Virtual WAN

Most people have used Azure Bastion before, the uptake of the ease of use product has been great and for years its 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 havent used it before, Azure Bastion is a resource that allows users to initiate a RDP-like connection over HTTPS to servers within Azure without the need to open ports, add public IP address or compromise security. It is secured by EntraID in the first case and a username/password is still required to authenticate to the VM.

Azure Bastion connection diagram showing how connections are made from an external client

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

Bastions direct connect feature from the Virtual Machine blade

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

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:

1. vWAN interconnects VNets through a Virtual WAN Hub (vWAN hub) controlling regional and global routing.
2. 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!
3. Inbound client connections reach Bastion directly, while outbound traffic traverses the firewall causing asymmetric routing 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.

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 | Microsoft Learn
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′

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.

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.