Microsoft® has finally provided VNET peering support for Azure Bastion. This offering has been a much-anticipated feature release, which I’m sure many folks are happy to see available.
Before this release, Azure® Bastion had an annoying limitation—it was not transitive, so its scope did not extend beyond a single VNET. This meant if you had multiple VNETs (which most environments typically do), then you’d need to deploy a Bastion in every VNET that had VMs that you wanted to manage remotely. Fortunately, that’s a thing of the past, and this new capability makes the service more useful, cheaper, and less complicated.
Microsoft has made both regional and global VNET peering available for Azure Bastion, so you can deploy the service in a single VNET and peer with VNETs in any public region around the world regardless of whether they are in the same subscription or not. This ability unlocks the possibility of deploying the Bastion in a common hub-and-spoke topology like the following design:
Source: https://docs.microsoft.com/en-us/azure/bastion/vnet-peering#architecture
For those of you who are new to the Azure Bastion service, I refer you to this Microsoft documentation, which does a great job of providing an overview of the product and its purpose.
In this example walkthrough, I use the Azure portal to deploy a Bastion in a hub VNET and show you the steps to successfully establish a connection through peering to target virtual machines (VMs) that reside in spoke VNETs. We will have one target VM in the same region as the Bastion and another Target VM in a different region.
Because this walkthrough focuses on deploying the Bastion and making the relevant connections, I won’t bore you with VM creation instructions. Therefore, I have already deployed the following in my subscription:
Windows® VM:
Linux® (Ubuntu operating system) VM:
By default, Microsoft associates the NSG to the VM NIC. For ease of management, I prefer to assign the NSGs to the subnet level instead. Therefore, I associated each respective NSG to the corresponding subnet and disassociated it from the VM’s NIC. The result is:
WindowsVM01-nsg <-> UKS-VNET01-SPOKE01-SN01
LinuxVM01-nsg <-> EUS-VNET01-SPOKE01-SN01
Use the following steps to go through this demo with me:
Bastion
. On the Results page, you should see the Bastion icon (verify the
publisher is Microsoft) and click Create.AzBastion01
), and select a region (I selected UK South
so it deploys in the same region as WindowsVM01).192.168.2.0/27
. This subnet is a dedicated subnet for the Bastion only, meaning you
deploy no other resources into it.Because the Bastion is a managed service, Microsoft hardens it by default. However, NSGs need to be applied to secure the subnet in which the Bastion host resides and apply the correct level of network access to the Bastion subnet as well as the subnets in which the target VMs reside so that the Bastion can connect to them successfully.
network security group
, and on the results page, you should see the Network
security group icon (verify the publisher is Microsoft). Go ahead and click Create.AzureBastionSubnet-nsg
), and select a region
(I selected UK South
so it deploys in the same region as the subnet I’m going to
associate it to).After you create the NSG, navigate to it and create the appropriate inbound rules. Click Inbound security rules under Settings. Notice three default rules from priority 65000-65500. You cannot delete these, but you can override them with rules that have a higher priority. Click +Add and create the following rules paying attention to the priority numbers:
Next, add the appropriate outbound rules. Click Outbound security rules under Settings. Notice three default rules from priority 65000-65500, and just like the Inbound default rules, you can’t delete these, but you can override them. Click +Add and create the following rules paying attention to the priority numbers:
As a reminder, the target VMs' subnets are UKS-VNET01-SPOKE01-SN01 (where WindowsVM01 resides) and EUS-VNET01-SPOKE01-SN01 (where LinuxVM01 resides). When I created the VMs, default NSGs already existed, and I reassigned them to the corresponding subnets. I now need to go to each subnet’s NSG and add the appropriate rule to each. I need to add only one inbound rule to each NSG as per the following:
Now, we need to configure peering between the Hub VNET where the Azure Bastion resides to each of the Spoke VNETs where the target VMs reside so that traffic can flow.
I start with peering the UKS-VNET02-HUB01 Hub VNET with UKS-VNET01-SPOKE01, where WindowsVM01 resides. Navigate to the UKS-VNET02-HUB01 VNET, select Peerings under Settings, and click +Add.
On the Add Peering page, start with the This virtual network section, meaning UKS-VNET02-HUB01 in this case, and make the following changes:
UKS-VNET02-HUB01-to-UKS-VNET01-SPOKE01
For the Remote virtual network section, meaning UKS-VNET01-SPOKE01 in this case, make the following changes:
UKS-VNET01-SPOKE01-to-UKS-VNET02-HUB01
After you click Add, Azure begins configuring peering connections on both of the VNETs, and you see a status like the following:
If you set up everything correctly, then you should now be able to connect to each VM by using the Bastion successfully. Let’s give it a go!
This post provides steps on implementing Azure Bastion in a hub-and-spoke topology model by using VNET peering and connecting to target VMs. This setup type allows you to centralize the Bastion host and simplify your remote management solution for server administration activities.
Learn more about our Azure services.
Use the Feedback tab to make any comments or ask questions. You can also click Sales Chat to chat now and start the conversation.