Integrating Azure Bastion in Azure Virtual WAN setup

Azure Virtual WAN is already in place and all branch sites are connected successfully. BGP peering is up, routes are propagating as expected and end to end connectivity is stable. You have also completed the migration from on-premises to Azure including the older management virtual machines that were previously used for administrative access. With that groundwork done you now want to modernize remote access by introducing Azure Bastion. After all keeping Windows Server jump hosts just to reach other virtual machines no longer makes much sense when Bastion can provide secure browser based access without exposing workloads directly. But when you kick off the Azure Bastion deployment it does not complete. Instead the deployment fails and an error is shown:

Why do I get this error message?

When we look into the following diagram we see the Azure Virtual WAN architecture. This service acts as a global networking layer that connects multiple virtual networks through a centralized hub. At the center of the architecture there is a VWAN Hub which functions as the main routing and connectivity point for the environment. Traffic between all connected networks flows through this hub, enabling centralized routing, connectivity, and network management. The dashed lines between the hub and the spokes represent the connections from each virtual network to the VWAN hub. This hub and spoke model ensures that communication between the networks is centrally managed and routed through the hub.

However this architecture introduces a challenge when Azure Bastion is used together with Azure Virtual WAN. Azure Bastion requires direct outbound connectivity to the public internet in order to operate correctly. In a Virtual WAN topology network traffic is typically routed through the Virtual Hub. Because the Bastion subnet has a default route of 0.0.0.0/0, its outbound traffic is also routed through the Virtual Hub instead of going directly to the internet. As a result Azure Bastion cannot meet its requirement for direct internet connectivity, which leads to compatibility issues and can cause the Bastion deployment to fail.

This is exactly the effect shown in the diagram above. To demonstrate this behavior, an Azure Virtual Machine was deployed in the Azure Bastion VNet in order to inspect the effective routes on the Network Interface Card. By reviewing the effective routes on the NIC, it becomes clear how the routing is handled in the Virtual WAN topology and how the default route influences the path that outbound traffic follows. This helps illustrate why traffic from the Bastion subnet is routed through the Virtual Hub instead of going directly to the public internet.

But why does this happen? The behavior originates from the Propagate Default Route setting within the Virtual WAN Virtual Network Connection towards the Azure Bastion VNet. When this setting is enabled, the Virtual WAN hub propagates the default route 0.0.0.0/0 to the connected virtual networks. This means that all outbound traffic that does not match a more specific route is automatically sent to the Virtual Hub. Because of this behavior, traffic from the Azure Bastion VNet would be routed through Azure Virtual WAN instead of going directly to the public internet. Since Azure Bastion requires direct outbound connectivity to the internet, this routing behavior causes a problem. To solve this, the Propagate Default Route setting was disabled on the Azure Bastion VNet connection. This ensures that the 0.0.0.0/0 route is not learned from the Virtual WAN hub, allowing outbound traffic from the Azure Bastion VNet to break out directly to the internet.

After applying this change we can verify the behavior again on the test virtual machine. When checking the effective routes on the network interface card we can now see that the 0.0.0.0/0 route forwards to the Internet service tag.

When deploying Azure Bastion again, our deployment succeeds! We can now succesfully use Azure Bastion within our Azure vWAN setup! 😍

From here you now know how to integrate Azure Bastion within an Azure Virtual WAN setup. This approach ensures that Bastion keeps the required direct internet connectivity while the rest of the environment continues to benefit from the centralized connectivity provided by Azure Virtual WAN. One of the advantages of this solution is the operational simplicity. It allows administrators to access virtual machines directly through the Azure Portal instead of having to deploy and manage separate jumpbox virtual machines. This reduces management overhead while still providing a secure and convenient way to connect to workloads inside the environment. Feel free to clap for this story. Also, let me know if you have any feedback. I look forward to our next session. That’s all for today, until then, take care! ❤️