In my previous blog post, I wrote about routing network traffic in a Hub/Spoke model. In this post I discuss the central deployment of Azure Bastion specifically within a VWan hub/spoke model.
Azure Bastion
Let's have a quick look at Azure Bastion first. In short: Azure Bastion is a solution to RDP into your Virtual Machines from the Azure portal, for example from outside your private network. It's ideal in situations like:
Cloud only environments.
(IT) Partners who need to connect to your Virtual Machines
Any other way of public access to your Virtual Machines while keeping them secure.
Why use Azure Bastion if you can use traditional RDP? To keep your VM's secure and disconnected from the public internet without a direct route from the internet open to your VM's, and without troubles and risks of manually managing public IPs for who can connect to your VMs.
For more information about Azure Bastion, see Microsoft Docs:
Many subscriptions/many bastions
Consider a large company existing from multiple branch offices or business units, or a smaller business with isolated services deployed. The company has external IT partners, and cloud-only administrators, not working from the private network.
You will have many subscriptions and VNets for each branch office or deployed services.
The security department requires all incoming traffic over port 22/3389 to be blocked to VMs, VMs cannot have a public IPs assigned. Although Cloud technology is all about PaaS and SaaS, you will always end up with deploying VMs for whatever reason.
Azure Bastion is probably your choice for connecting with RDP for at least a part of your IT Staff and partners. The thing is, if you don't overthink things and don't plan ahead, you will probably end up with multiple Azure Bastions deployed, possibly with multiple Bastions within a subscription due to limited interconnectivity between services. With a basic Bastion costing almost $140,- / €120,- can become quite pricey.
Azure Bastion deployment with VWan hub/spoke
As mentioned before, the previous post was about the hub/spoke model. A modern hub/spoke for larger companies with branches across the world will probably have a VWan deployed with VNets attached to them acting as a spoke.
You might think let's create a bastion spoke and all VMs can be accessed via the Bastion.
"Azure Bastion is incompatible with global peering"
But no, after you have everything set up with Bastions deployed, you're ready to connect to a VM only to discover that no Bastions are available to select.
One of the limitations of Bastion is Azure Bastion is incompatible with global peering, and VWan VNet peering is global peering, as VWan is sat outside your tenant.
Bastion Hub/Spoke
The solution: deploy a separate hub/spoke for your Azure Bastion.
What would it look like? You would create a second hub specifically your Bastion, let's call it the Bastion Hub.
"The solution: deploy a separate hub/spoke for your Azure Bastion"
I made below Architecture diagram to show you what a separate Bastion Hub next to your primary hub/spoke would look like.
Secure the Bastion Hub
Naturally you want your environment to be secured. Every VNet should be deployed with a Network Security Group (NSG). Therefore, you should also deploy an NSG on your Azure Bastion subnet.
NSG Rules for AzureBastionSubnet
Azure Bastion must be deployed to a subnet called AzureBastionSubnet. You should always deploy an NSG on every subnet you create. Below are the rules to created in an NSG connected to you Bastion subnet:
Inbound
TCP 443 from internet to Azure Bastion.
Outbound
TCP 22 from Azure Bastion to Service Tag: VirtualNetwork
TCP 3389 from Azure Bastion to Service Tag: VirtualNetwork
NSG Rules on your spoke subnets
When you have VMs deployed to a subnet which should be accessible by your Bastion, you should include the below rules. You could consider deploying these rules as default to every subnet created. You can for example use policies to make sure the rules always exist, or tag the subnet when VM's are deployed so that the rule only exists on subnets that should be accessible by Bastion.
Inbound
TCP 22 from Azure Bastion to either you VM or any resource.
TCP 3389 from Azure Bastion to either your VM or any resource.
Outbound
No outbound rules required on the spoke subnets where VMs are deployed..
Prevent unwanted routing
When you have two hub/spoke models, be careful with routing. As Azure is dealing with network traffic routing for you.
By the way, did you know that all peered VNets including VNets behind transit routing, are part of the 'VirtualNetwork' tag as mentioned in default rule: AllowVNetInBound with priority: 65000, and thus all traffic any port is allowed.
The last thing you want is your network configured securely with a primary hub with Azure Firewall configured, while all your traffic is going via a secondary unprotected route.
"all peered VNets including VNets behind transit routing, are part of the 'VirtualNetwork' tag as mentioned in default rule: AllowVNetInBound with priority: 65000"
To prevent the above horror situation to happen, make sure that whenever you peer your VNet with the Bastion Hub, the right configuration is applied.
Make sure:
Allow virtual network access is Enabled
Allow forwarded traffic is Disabled
Allow gateway transit is Disabled
In my previous blog post I explained the meaning of each of these options.
With the above configuration applied, network traffic can only travel into the Bastion Hub VNet and cannot leave the VNet to other networks.
Conclusion
Azure Bastion is incompatible with global peering, and therefore incompatible with VWan peering.
If you want to deploy a central Bastion Service for your company with multiple subscriptions and VNets. Where you're preferred deployment is a hub/spoke, then you could consider a second hub/spoke model specifically for Bastion.
Make sure you consider the right NSG ruling and especially configure your routing properly to prevent network traffic to take an unmanaged route.
As far as I know, this is the only centrally managed Bastion deployment in a VWan hub/spoke model.
If you know an alternative central deployment in combination with VWan, please share it in the comments.
Comments