Azure Bastion in a Virtual WAN architecture

Azure Virtual WAN does an amazing job bringing network functionalities together in one management plane. However, for Azure Bastion in a Virtual WAN, things get more difficult in comparison to a traditional hub-spoke model. In today’s post, we find out why that is and how you deploy Azure Bastion in a Virtual WAN architecture.

The problem

You cannot deploy Azure Bastion within Virtual WAN. It simply isn’t supported because the service needs a direct route to the internet. Routing over the Virtual Hub is a no go and something like a user-defined route on the Bastion’s subnet is also not possible. And that’s unfortunate, because it would be so nice to centrally deploy, manage and offer it within the Virtual Hub. Luckily, there is an alternative which we explore in the sections below.

Solution: Azure Bastion spoke

The solution to the problem is a new virtual network (spoke) peered to our Virtual WAN infrastructure which is specifically for Azure Bastion. By deploying a new Hub Route Table with a static route to the Azure Firewall, we still control the traffic flow from- and to other virtual networks. All other traffic that is not internal, will be routed directly to the internet. We use this Hub Route Table for the Bastion’s Virtual Network Connection to the Virtual Hub.

As a result, we can use IP-based connections from Azure Bastion to a virtual machine in a peered virtual network over the Azure Firewall in the Virtual Hub.

Overview

As a start, lets briefly discuss the components used that helps us setting up Azure Bastion in a Virtual WAN architecture:

• Infrastructure: There is one Virtual WAN and one Virtual Hub.
• Virtual Hub: Within the Virtual Hub, an Azure Firewall is deployed providing network segmentation and inspection.
• Peering: All virtual networks (spokes) are peered to the Virtual Hub with a Virtual Network Connection.
• Route tables: We deploy two route tables in the Virtual Hub, which we will cover in detail later.
• Azure Bastion: Deployed in a centrally managed virtual network.

Minimum SKU’s

It’s crucial to choose the correct SKUs for required functionalities. The Standard SKU is needed for both the Virtual WAN and Bastion service to support Azure Firewall and secure connections to VMs respectively. For the Azure Firewall and Firewall Policy, a Basic SKU is sufficient, providing minimal necessary features for this specific deployment scenario.

Network and routing

The network infrastructure involves three distinct segments:

• Virtual Hub network.
• Spoke virtual network for virtual machines.
• Spoke virtual network for Azure Bastion.

The address space for the Bastion’s virtual network is intentionally set aside to illustrate the setup. In a real world scenario it’s perfectly fine to pick an address space that fits within your IP plan.

Route tables

Setting up two different route tables in a Virtual Hub helps manage and guide network traffic effectively.

• Internal: Is the default for all spoke virtual networks, forcing all traffic to the Azure Firewall in the Virtual Hub.
• Bastion: For Azure Bastion only. This table ensures that the Bastion service can reach the internet directly but internal traffic still routes over the Azure Firewall.

Note: More information about why force-tunneling internet traffic for Azure Bastion doesn’t work can be found here.

Deployment

To demonstrate Azure Bastion in a Virtual WAN architecture, we explore the following actions:

• Route table: Configure a new route table inside of the Virtual Hub.
• Hub Virtual Network Connection: Peer the virtual network to the Virtual Hub.
• Firewall rules: Deploy the required network rules to allow RDP and SSH traffic to virtual machines in spoke networks.

Note: The deployment of Virtual WAN, Virtual Hub, Azure Firewall, Virtual Network and Azure Bastion is not included in this post.

Hub Route Table

Azure Bastion needs to phone home over the internet via a direct route for management purposes. Therefore, it isn’t supported to route this traffic over the Azure Firewall. Given this limitation we need to configure a Hub Route Table with a static route to the internal address space.

As a result it:

1. Forces IP-based connections initiated from Azure Bastion to the Azure Firewall.
2. Routes all other traffic that doesn’t match this route directly to the internet.

@description('Reference to the existing Virtual Hub.')
resource resVirtualHub 'Microsoft.Network/virtualHubs@2023-09-01' existing = {
  name: 'vhub-01'
}

@description('Reference to the existing Azure Firewall which is used to route traffic to.')
resource resFirewall 'Microsoft.Network/azureFirewalls@2023-09-01' existing = {
  name: 'afw-01'
}

@description('Deploys a route table with routes within the given Virtual Hub.')
resource resHubRouteTable 'Microsoft.Network/virtualHubs/hubRouteTables@2023-09-01' = {
  name: 'bastion-rt-01'
  parent: resVirtualHub
  properties: {
    labels: []
    routes: [
      {
        destinations: [
          '10.0.0.0/8'
        ]
        destinationType: 'CIDR'
        name: 'internal'
        nextHop: resFirewall.id
        nextHopType: 'ResourceId'
      }
    ]
  }
}

Virtual Network Connection

Create a Virtual Network Connection to the Virtual Hub for Bastion’s virtual network. Within this connection, we populate the resource identifier of the Hub Route Table deployed specifically for Azure Bastion.

@description('Reference to the existing Virtual Hub.')
resource resVirtualHub 'Microsoft.Network/virtualHubs@2023-09-01' existing = {
  name: 'vhub-01'
}

@description('Reference to the existing Virtual Network.')
resource resVirtualNetwork 'Microsoft.Network/virtualHubs@2023-09-01' existing = {
  name: 'vnet-01-bastion'
}

@description('Reference to the existing Hub Route Table.')
resource resHubRouteTable 'Microsoft.Network/virtualHubs/hubRouteTables@2023-09-01' existing = {
  name: 'bastion-rt-01'
  parent: resVirtualHub
}

resource resVnetConnection 'Microsoft.Network/virtualHubs/hubVirtualNetworkConnections@2023-04-01' = {
  name: 'vhub-conn-bastion-01'
  parent: resVirtualHub
  properties: {
    enableInternetSecurity: true
    remoteVirtualNetwork: {
      id: resVirtualNetwork.id
    }
    routingConfiguration: {
      associatedRouteTable: {
        id: resHubRouteTable.id
      }
    }
  }
}

Firewall

Assuming you now have:

1. Azure Bastion deployed in its own Virtual Network.
2. Configured the Hub Route Table with a static route to the internal network.
3. Active Virtual Network Connection from Bastion’s virtual network to the Virtual Hub.

This leaves us with one more thing to configure: firewall rules. You obviously connect to a virtual machine somewhere in your peered networks and that needs to be allowed. In the example below, we specify that we allow SSH and RDP traffic from the Azure Bastion virtual network to our internal network over TCP/UDP.

Note: The firewall rule provided above is just an example. It is advised to allow SSH/RDP traffic from Azure Bastion to selected virtual networks only.

Connect to a virtual machine

To connect to a virtual machine, you make the connection from Bastion’s resource pane in the Azure portal. Unfortunately, this is the only way to connect to the virtual machine.

1. Azure Bastion: Navigate to the Azure Bastion resource in the Azure portal.
2. Connect: On the Connect page, enter the IP address of the target virtual machine.
3. Connection Settings: Specify the connection settings.
4. Credentials: Enter your credentials for the virtual machine.
5. Connect: Select Connect.

Conclusion

In conclusion, while the integration of Azure Bastion into a Virtual WAN architecture presents a unique set of challenges due to its requirement for direct internet access, the structured approach laid out in this post offers a viable solution. By creating an Azure Bastion-specific spoke within the Virtual WAN and configuring the Hub Route Table to facilitate proper routing, organizations can effectively deploy and manage Azure Bastion services. This ensures secure, IP-based connections to virtual machines while maintaining the centralized control and oversight that Virtual WAN provides.

Through careful planning of SKUs, network and routing configurations, and firewall policies, Azure Bastion is successfully integrated into the Virtual WAN, leveraging best practices for both security and functionality.

Documentation

• Microsoft Docs – Does Azure Bastion support Virtual WAN?
• Microsoft Docs – Connect to a VM via specified private IP address