Microsoft lets you bring you own network (BYON) into Windows Azure. You can connect your local area network (LAN) to Azure and an unlimited number of computers on your corporate networks can seamlessly communicate with VMs in Azure. You can specify private network spaces (such as 192.168.x.x and 10.x.x.x) in any range, size, and starting number to suit your existing network topology. Just snap a route to Azure alongside your other branch, remote office, DR site, and partner IPSEC tunnel connections.
If you are already using IPSEC tunnels to connect over the Internet, this is familiar technology. What’s amazing is how easy it is to set up once you understand the Azure Virtual Network concepts. The ease of configuration and provisioning of the Virtual Network (on the Azure side) was a quick and pleasing experience, just like provisioning the Azure IaaS VM. Two important tests were passed: (1) On a supported VPN hardware endpoint, Azure Virtual Network worked right on the first try and (2) the Azure IaaS VM was able to join the on-premise Active Directory domain immediately.
Azure Virtual Network’s fit in the public cloud
Previous articles covered deploying an Azure IaaS (Infrastructure as a Service) class Virtual Machine (VM) in less than 15 minutes, and the Metro-UI experience of monitoring the new IaaS VM from the Azure management portal. Microsoft’s public cloud platform, Windows Azure, has two existing networking features: Windows Azure Connect and Traffic Manager. Traffic Manager load-balances incoming traffic across multiple hosted Windows Azure services; Windows Azure Connect is a point-VPN solution that connects one machine to an Azure machine.
This article covers the new Virtual Network service, (see Figure A) which lets you provision and manage virtual private networks (VPNs) in Windows Azure as well as securely link these with on-premises IT infrastructure. With Virtual Network, you extend on-premises networks into the cloud with control over network topology, including configuration of DNS and IP address ranges for VMs. This is about scaling your network into Azure or moving infrastructure roles into Azure as it makes sense.
Azure Virtual Network Dashboard in the Azure management portal. (Click to enlarge images.)
The exciting news is that with Azure Virtual Network you can use familiar site-to-site VPN tunnel technology to securely extend your on-premise or private cloud datacenter capacity out into the public cloud. As many machines as you want behind the VPN gateway can then communicate with the computers in Azure. Hybrid cloud scenarios are instantly and cleanly enabled without deploying any software in your environment and using private network numbers you assign to work in harmony with your existing LAN, WAN, and VPN networks.
Azure Virtual Network architecture
Setting up the Virtual Network in the Azure management portal was a breeze once the underlying routing scheme (that is, the network and subnets) was understood. Figure B summarizes how you need to select and subnet your Azure Virtual Network. On the left in Figure B is your existing LAN. At your premise edge, you have a supported hardware IPSEC VPN endpoint. The IPSEC tunnel terminates at the Azure firewall in a Gateway subnet which is a subnet of the Azure Virtual Network you selected.
Azure virtual networking concepts include a gateway and a server subnet.
In other words, when setting up your Azure virtual network, you select a larger network range in Azure than you need for your IaaS VMs, and then carve out a subnet for use as the ‘Gateway Subnet”. Azure will deploy your VMs into an additional subnet you specify for servers. IaaS VMs will receive addresses via DHCP in the ‘Server Subnet’ range you specified.
Another key concept is that you define a Virtual Network in Azure, and then deploy VMs into it–that is how VMs get the correct addressing-you can’t change network settings with VMs deployed to the network. To modify the Virtual Network (other than to add subnets), you have to tear down the VMs and redeploy them into the new Virtual Network.
BYON okay, but BYOND limited to a few models
Azure only lets you bring your own networking device (BYOND) if it is on a short list of supported hardware endpoints. Figure C shows a Cisco ISR router above, and a Juniper multipurpose router below. Only specific models of devices from these two vendors are supported in the Azure Virtual Network trial. Microsoft provides detailed configuration guidance on these models, and no help with any other vendor’s IPSEC endpoint, not even Microsoft’s own TMG/ISA firewall products.
Specific hardware devices from Cisco and Juniper are required to access Azure VPN.
I first tried to get Azure Virtual Network to work using Microsoft’s own software firewall, Threat Management Gateway (TMG 2010). Pleas to the Azure support forum were ignored, because the Azure management portal offers no feedback on why your IPSEC tunnel might not be working on the Azure end. It either connects or not, simple. In a second attempt, switching to a non-supported hardware firewall from another vendor was also fruitless. Finally, there was prompt success after procuring a supported Cisco ISR-series router (top of Figure C) and configuring it as directed at the Azure portal.
Pushing the Download button at the bottom of Figure A accesses a text file with configuration commands specific to your model of device. Pushing the View Key button allows for cut and paste of the pre-shared key passcode. Between the configuration commands and the pre-shared key, this was all I needed to configure the Cisco ISR router to connect Azure Virtual Network to my local network.
IaaS VMs deployed to your Virtual Network use DNS servers of your selection, even your on-premise Active Directory DNS servers. This lets Azure IaaS VMs join your on-premise AD domain, and be managed with existing monitoring and management tools — as if they were on-premise. You will forget which of your domain servers are in Windows Azure and connected by Azure Virtual Network-until you get the monthly bill!