There are a few ways you can connect to Azure virtual machine (VMs), some more secure than others, but over the last couple of years we’ve defaulted to Azure Bastion where we can. The problem arises when you try and use Bastion whilst you’re using Azure Virtual WAN because you can’t deploy the Bastion in the managed hub VNet.
Azure Bastion
Azure Bastion is a fully managed platform-as-a-service (PaaS) solution offered by Microsoft, designed to provide secure and seamless RDP/SSH connectivity to Azure virtual machines (VMs) over the internet, without the need for a virtual private network (VPN) connection or public IP addresses.
Traditionally, accessing Azure VMs remotely requires opening a port in the VM’s network security group (NSG), which can expose the VM to potential security threats. Alternatively, a VPN connection can be set up to provide remote access to VMs, but this can be complex and requires additional infrastructure.
With Azure Bastion, remote access to VMs is provided through a browser-based SSL-encrypted gateway that uses Remote Desktop Protocol (RDP) or Secure Shell (SSH) protocols. The access is provided through a dedicated IP address and managed by Microsoft, which helps to ensure security and compliance requirements are met.
Azure Bastion simplifies remote access to VMs in Azure by providing a secure and easy-to-use platform that eliminates the need for complex VPN setups or exposing VMs to potential security threats. It also reduces the risk of credential theft, as it supports multifactor authentication (MFA) and role-based access control (RBAC).
Azure Virtual WAN
Azure networking has also advanced rapidly over the last couple of years and we’ve been using Azure Virtual WAN a lot more.
Azure Virtual WAN is a networking service offered by Microsoft Azure that provides a simplified and optimized network connectivity solution for connecting different Azure regions, on-premises sites, and remote branches.
It allows customers to create a unified, global network that spans multiple regions, simplifies network architecture, and enables secure and optimized connectivity. With Azure Virtual WAN, customers can connect their remote sites and on-premises data centres to Azure resources using a highly available and resilient infrastructure.
Azure Virtual WAN provides features such as centralized management, routing, and monitoring. It uses a hub and spoke topology, with the hub acting as a central point of connectivity and the spokes connecting to the hub. The hub is implemented using a Virtual WAN Hub, which acts as a hub for network traffic and manages connections from the spokes.
Overall, Azure Virtual WAN helps to simplify network infrastructure, improves application performance and reliability, and provides secure connectivity between different resources.
Using Bastion with Virtual WAN
But, using Bastion to connect to VMs in a Virtual WAN doesn’t work with the out of the box Bastion configuration. You typically configure Bastion in the hub VNet of a traditional hub-and-spoke topology. You can then use Bastion to connect to any VMs peered to the hub VNet. But when you use Azure Virtual WAN the hub VNet is managed by Microsoft and you can’t configure the Bastion in the hub so you have to configure it in a spoke VNet. That’s fine for VMs in that spoke VNet but it means you can’t connect to VMs in other spokes.
To connect to VMs in other VNets with Bastion whilst using Azure Virtual WAN you have to enable a setting on the Bastion called IP-based connection. The IP-based connection for Azure Bastion refers to the connection method that uses an IP address to establish a secure connection between the user and the virtual machine. It allows you to connect not only to your Azure VMs but also to your on-premises and non-Azure virtual machines This method uses the Remote Desktop Protocol (RDP) or Secure Shell (SSH) protocol to connect to the VMs.
Once you’ve enabled IP-based connection an additional link appears under the Settings on the left called Connect. Select Connect and you can then enter the IP address of the machine you want to connect to.
Conclusion
This approach provides an additional layer of security by ensuring that the VMs are not directly exposed to the internet, and eliminates the need for VPN connections or the opening of inbound ports on the virtual machine’s network security group. It also simplifies network management and enhances security by providing a centrally managed and secured connection to on-premises resources.
