When you have a virtual network running in Azure which has been connected to an on-premises network using a VPN or ExpressRoute, the default routing behaviour for all VMs in that virtual network is that all traffic to and from the VMs routes over the connection to the on-premises network.
This makes sense as a default position, because it means that the virtual network is, in effect, simply an extension of the on-premises network, and all the existing network controls which may be in place (such as proxies) continue to work as before.
The problem is that this default routing behaviour breaks other functionality, such as:
- Public endpoints in Azure which connect to the virtual network don’t work
- Windows-based VMs running in Azure cannot activate against Microsoft’s KMS service
- Access to Azure-based services like Azure Storage or Azure Recovery Vault routes over the private connection and out through the private internet link, rather than using the Azure datacenter internet link
All of these issues can be resolved by creating User Defined Routes (//azure.microsoft.com/en-us/documentation/articles/virtual-networks-udr-overview/) and configuring these to give the VMs direct access to Azure services in one or more geo-political regions. Microsoft does make this information available for download (//www.microsoft.com/en-au/download/details.aspx?id=41653), but the problem is that the data changes regularly, so clearly creating and maintaining routes using any kind of manual process isn’t going to work.
At the moment, Microsoft doesn’t expose the public IP ranges of the Azure datacenters via the Azure REST APIs, although I understand that this is going to change in the not-too-distant future.
Fortunately, Kieran Jacobsen has written a PowerShell module which downloads and extracts the IP data from the spreadsheet which Microsoft publishes. This means that it is possible to automate the creation and maintenance of User Defined Routes which will give your IaaS instances direct access to Azure datacenter public IPs.
I’ve written a script which is designed to be run on a schedule within Azure Automation, although it can also be easily re-worked to run as a standalone script or via some other automated mechanism. The script and some explanatory documentation is located on GitHub:
Have a play with the script and please feel free to suggest any improvements 🙂