One of the great new Azure features announced at TechEd 2014 in Houston is the capability of assigning public IP addresses directly to VMs on an instance-level. As these IP addresses are public (that’s why they’re also called PIP) they allow you to access your VMs directly from outside the datacenter, without having to define any endpoints on the virtual IP address (VIP) of the corresponding cloud service.
This can be handy for example if you need to access your Azure VMs via RDP from your corporate environment and your firewall admin has blocked ports other than the ‘mainstream’ ones (80, 443, 3389, …). If you have deployed multiple VMs in a single cloud service, the Azure load balancer provides port forwarding to those VMs from random high ports to port 3389 internally. If your firewall blocks those high ports you’re stuck. PIPs to the rescue! This post will describe what it takes to create a PIP for a VM and how to avoid common pitfalls.
Create a Wide VNet
The first thing to note is that you can only assign a PIP to a VM that is deployed inside a virtual network. In other words: VMs in ‘stand-alone’ cloud services cannot have a PIP (at least today). Additionally the VNet has to be a ‘wide’ VNet. That’s sort of the next generation of virtual networks in Azure that are not restricted to single affinity groups, but rather span across an Azure region (e.g. West Europe). This new concept allows deployment of way more VMs into a network than with the original approach, where an affinity group is restricted to a single cluster in the datacenter.
But how do you create a wide VNet? If you are an Azure old-timer you know that you have to associate a VNet with an affinity group when creating it in the management portal, and that’s actually still the case. The workaround (until this will be enabled in the portal) is to use the export/import feature for your network configuration. If you want to create a brand new (wide!) VNet, follow these steps:
- Export your current network configuration via the ‘Export’ button in the management portal. This will let you download an XML file.
- Open that XML file and add the following configuration under the <VirtualNetworkSites> tag (replacing names and address ranges with your preferred values):
<VirtualNetworkSites> ... <VirtualNetworkSite name="widevnet" location="West Europe"> <AddressSpace> <AddressPrefix>10.0.0.0/8</AddressPrefix> </AddressSpace> <Subnets> <Subnet name="main"> <AddressPrefix>10.0.0.0/24</AddressPrefix> </Subnet> </Subnets> </VirtualNetworkSite> </VirtualNetworkSites>
Note, that instead of an affinity group you will have to specify the region via the location attribute! If you do so you will get a wide VNet.
- Now import the configuration in the portal via New – Network Services – Virtual Network – Import Configuration, selecting your updated XML file.
- Voilà, in the Virtual Network section of your portal you can now see the new VNet. Make sure it is showing the region you specified above in the Location column:
Deploy a VM
Now you can deploy your VM into the VNet you have just created. Go ahead and do that with your favorite deployment approach (Portal, PowerShell, CLI, etc.). Just for fun create the VM without any endpoints, as we will access the machine via RDP using the PIP we are going to create in a moment.
Once the VM has come up, go to the Dashboard page in the portal and take note of the external (VIP) and internal IP addresses. In my example the Azure fabric assigned a VIP of 188.8.131.52:
Assign a PIP
Now, open a PowerShell console. Yes, unfortunately at the time of writing, assigning a PIP in the management portal is not yet possible, but will certainly be coming soon. In order to assign the instance-level public IP address execute the following statement (after having authenticated and selected the proper Azure subscription):
Get-AzureVM -ServiceName "yourservice" -Name "yourvmname" | Set-AzurePublicIP -PublicIPName "yourpipname" | Update-AzureVM
Make sure to insert your specific names for the service, VM and PIP. In case the PIP was created successfully PowerShell will return OperationStatus Succeeded. In case of an error (e.g. when trying to create a PIP on a VM in an ‘old-style’ VNet you will see the following error:
As there is currently no way to see the PIP in the management portal, again you will have to use a PowerShell statement:
Get-AzureRole -ServiceName "yourservice" -InstanceDetails
This will return a list object containing details about your VM, including the PIP we’ve just created:
As you can see, this IP is different from the VIP we have seen above. The VIP was 184.108.40.206, whereas the PIP is now 220.127.116.11.
RDP into the VM
As we have omitted all public endpoints when creating the VM, the Endpoint section of the VM in the portal should look like this (i.e. be empty):
So, go ahead and open your RDP client (if you’re on Windows type mstsc in the Windows-Run console.
In the RDP window enter your specific PIP address:
And that’s it! You should be able to remote desktop into your VM via the PIP without having any ports open on the VIP of the cloud service. Note, that when you will execute an ipconfig within the VM you will not see the PIP, as it is managed by the hypervisor hosting your VM.
Shutdown and Restart your VM
So, what happens if we shutdown (i.e. deprovision) our VM and restart it later on? Will it remember that it was assigned a PIP and bring it up again? Will it even have the same IP address? Well, let’s try…
Shutdown the VM in the portal (don’t do it in the RDP session). This will deprovision the machine, i.e. release the cloud service deployment and you will stop to pay for compute time. The Status column in the Dashboard section of the portal should show Stopped (Deallocated). Then start the VM again and wait for it to come up. Repeat the Get-AzureRole PowerShell statement shown above in order to find out if we still have a PIP.
As you can see, the VM remembered that it was assigned a PIP and created a new one (in my case 18.104.22.168). Although it is currently not possible to reserve a fixed PIP address (as you can now do with VIP addresses as announced at TechEd), the VM keeps it’s configuration which is quite cool.
It’s a Preview
At the time of writing, PIPs are in public preview (no registration required, though) and free of charge. As you’ve seen above, there is no integration into the management portal yet and also some prerequisites you have to be aware of. Today, you can assign one PIP per virtual machine, and there’s a maximum of two PIPs per Azure subscription.