There may be a valid reason why you need Remote Desktop Protocol (RDP) or Secure Shell (SSH) access to a virtual machine hosted in Microsoft Azure. Unfortunately, this means you either need to have ports like 3389 open on a public IP address (and therefore discoverable to hacking attempts), or you need to manage a separate “jump box” as an interim step to route your connection through.
Now in public preview, Azure Bastion provides easy, secure remote access into Microsoft Azure VMs through the Azure Portal in a browser, without the need for those VMs to have a public IP address. This Platform as a Service offering is managed & updated by Microsoft and is configured per virtual network where your VMs reside. The Azure Bastion Host itself has a public IP address but only requires port 443 to be open for HTTPS.
And while the ease of setup and access will blow you away – wait until you see what is on the roadmap: seamless single sign-on, Azure Active Directory authentication, multi-factor authentication, support for native RDP/SSH clients, support for other Azure resources .. and that’s just the start!
Things to note: Access during public preview – To see Azure Bastion as an option, you’ll need to use the Preview Microsoft Azure portal at https://aka.ms/BastionHost
Available regions - Azure Bastion is currently available only in the following regions: West US, East US, West Europe, South Central US, Australia East, Japan East. It must be deployed in the same region as the vnet it is providing access to (that is, the same vnet that your VMs are using). If you have VMs deployed across more than one vnet, you’ll need an Azure Bastion host in each vnet.
Pricing – You will only be partially billed during the public preview (as public previews do not come with SLAs). Full pricing is available here. Once deployed, Azure Bastion hosts are currently always on.
Setting up Azure Bastion: • Following the instructions to Create a bastion host (preview) was quite straightforward. You’ll find Bastion in the Azure Marketplace, or clicking Connect in an existing VM will prep-populate some network settings relevant to that VM.
• It’s important to check the configuration of your virtual network. The vnet address space sets the maximum amount of IP addresses available using CIDR notation.
In my case, my existing vnet address space was 10.0.0.0/24, allowing for 256 addressses (actually 251 + 5 reserved for Azure). I already had a subnet configured called “default” as 10.0.0.0/26. This allows me to use 59 of those addresses (64 - 5 reserved for Azure) for things I configure to use that default subnet (like my VMs).
Azure Bastion requires it’s own subnet named AzureBastionSubnet with a CIDR of at least /27 (for future Auto Scale support). By configuring that new subnet to be 10.0.0.64/27, I’m not conflicting with the IP addresses already reserved in the default subnet, and I still have more available addresses spare in the vnet address space. Your configuration may vary, but if you are getting a red error during your subnet configuration, it’s likely to mean that you need to increase the CIDR of the vnet address space (to allow for more addresses overall), or your starting IP address number is too low and it conflicts with an existing address already in another subnet.
• If your VMs only had existing public IP addresses for administrative RDP/SSH support, once Azure Bastion is configured and tested successfully you can disassociate the public IP address from the VM and then delete it. Just remember to leave the public IP address in place that is connected to your Azure Bastion host itself!
• Because Bastion hosts are Azure resources, you can add tags to them, lock them to prevent accidental deletion, and export them as a .JSON template.
• I found connectivity to my VMs was fast, and the browser connection supports reading from my host PCs clipboard (text and images) once I’ve allowed it, but not the transfer/copy paste of any files from my PC to my virtual machines.