Now that Microsoft has officially released Azure Infrastructure Services, you may be anxious to get started with deploying Virtual Machines "in the cloud" and start using them with your existing corporate infrastructure...and you should! But first you need to prepare the Virtual Networking in Azure, and then you can establish a Site-to-Site VPN so your Azure VMs can talk to your Corpnet VMs and resources. After you have the networking squared away, that's when you start building those VMs!
I think it helps to group the tasks of establishing the Site-to-Azure VPN in two sets, the Azure network and the Corpnet network. This article will focus on the Azure side, and I have another one for the Corpnet side. Here's what we'll cover:
After that, you're ready to configure the Corpnet side of the VPN tunnel. So let's get started.
Why Azure Infrastructure Services?
You can literally think of Azure as another site, or a branch office of sorts; a true extension of your corporate network. The only difference is you don't have to buy or rent any real estate, pay the electric bill or arrange any Internet service contracts, nor buy any physical servers or monitor the hardware for failures...at least not directly. All the Capital and Operating Expenses of running another company site are nicely rolled up into a single, predictable monthly subscription to Azure. You just build the Virtual Machines and Microsoft takes care of ensuring they are highly available.
I won't go into a ton of detail on Azure itself, but before you build a Virtual Machine, you really need to configure the networking first, because (at least for now) once you've deployed a VM into Azure, you cannot simply move it to a different network. This has to do with the way the Virtual Network inside the Azure service is secured and is outside the scope of this article.
Network Topology Example
There are several things that you will need to know before you actually configure anything in Azure or at the Corpnet, so this is where a little planning comes in. You will be creating a new IPv4 Network and Subnet in Azure that does not overlap with a subnet that is already in use at the Corpnet.
Let's say for example that you already use a subnet of 10.26.x.x (a /16 in CIDR notation) at your corporate network, and you want to establish a new 10.30.x.x network (another /16) in the Azure site. This new 10.30 will be used by Azure to define new smaller Subnets that can establish routes to the Internet, including one which will be where the virtual vpn device or "gateway" is created. Other subnets within that larger subnet is where the Virtual Machines will actually be connected.
So for example, you could create a 10.30.0.x network (a /24) to be used by the Gateway service and a 10.30.1.x network (also a /24) for the VMs, or any other set of 10.30.somethings that will fit within the /16 network. It might look something like this.
You will need to know the IP addresses / Ranges that are appropriate for your network needs. Azure will assign you the "a.a.a.a" address later as you complete this guide. The "c.c.c.c" address is the public IP address of your VPN device that will be used to establish the site-to-site IPSec vpn.
And with that, you're ready to start setting things up in Azure! If you don't already have an account, you can get a 90 day free trial to kick the tires, and it won't cost you a dime.
Create an Affinity Group and Virtual Network
Because Azure is actually a globally dispersed hosting service, you will need to decide where in the physical world your Virtual Machines should be located. Microsoft describes these geographical areas with their physical datacenters as Regions. Your decision to place a VM in one Region or another will determine where in the physical world their Network traffic will hook up with the Internet, as well as how (or if) they will be able to talk directly to another Virtual Machine that you might also have hosted in Azure.
For example, if you just want to build a stand-alone virtual machine that has nothing more than a NAT'd connection to the Internet, then you can simply build a VM and assign it to a Region. But, if you want to have multiple VMs that talk to each other inside the Azure service, then you need to first create a Virtual Network that they will be attached to. In order to tie Virtual Machines with Virtual Networks, Azure uses a logical component called an Affinity Group that also ties those resources to a Region and keeps all the resources in the same Datacenter.
From the Settings section, select the Affinity Groups tab, then click Add, give the group a Name and select a Region.
Note: At the time of this writing, there is a Region called "North Central US" that I do not recommend you use because this Region is not available as a Location for virtual Machines to be deployed. So pick any of the others, but avoid North Central US...at least until it's also in the Location list for VMs.
Next we will define the "Local Network" which defines the properties of your existing Corpnet.
From the New menu, select Networks > Virtual Network and then Register Local Network.
Give it a Name and enter the Public IP address of the Corpnet VPN device that will connect to the Azure site. Click the arrow in the bottom right corner to continue to page 2.
Populate the Address Space with the Subnet(s) that are available at the Corpnet and click the Check to finish.
Now let's define the IP addresses of DNS servers that you want the VMs in Azure to use for name resolution. We will want all VM's to a use Corpnet DNS servers to be able to resolve your Windows Domain servers, so we need to add the IP's of at least one of your Domain Controllers on the Corpnet.
Click New > Networks > Virtual Network > Register DNS Server and enter the Name and IP of your corpnet DC. Repeat to add a second DC if desired.
Now that the Corpnet side of things is established (at least as far as Azure is concerned), it's time to create the Azure Virtual Network!
Click New > Networks > Virtual Network > Custom Create
Give it a Name and select the Affinity Group that you created earlier.
If you click on the CIDR box you can define the Address space using slash notation. Enter the larger subnet for the Address Space, then add the Subnet that you want to use for your Virtual Machines.
On this third page, select the DNS Server(s) that you want your VMs to use, then check the option to "Configure a connection to the local network" and define the Gateway Subnet that you want to use. Also select the Local Network that you defined for your Corpnet earlier.
Now that the Network has been created, it's time to create the Gateway to the Corpnet.
From the Networks section, click on the Virtual Network you just created, select the Dashboard and then click Create Gateway.
Once the creation request is submitted the link will turn yellow and say "Creating Gateway". This part can take quite a while to complete while Azure creates the device and fetches you a public IP address. Expect to wait maybe 5-15mins before the dashboard refreshes with the new information.
Once the Gateway is created, the screen will refresh and show you the Gateway IP Address which is the public IP address that has been assigned to your Virtual Network Gateway. You are now all done configuring the Azure Network settings!
The final thing you'll want to do here is click on the Manage Key icon to get the Preshared Key, a somewhat long string of random numbers and letters, which you will use later when you configure your Corpnet VPN device to actually establish the VPN Connection to Azure. Think of it as a sort of password. You can always come back later to copy it again if you need to.
Create a Virtual Machine
Now that you have a Network in Azure, you're ready to deploy a virtual machine to it! Thankfully, Azure has a pretty great Gallery from which you can deploy any variety of pre-built servers, but you can also upload your own image in the form of a Virtual Hard Drive if you wish. For this example, we just want to deploy something that can be use for connectivity tests, so we'll keep it simple.
Click New > Compute > Virtual Machine > From Gallery.
Do not use Quick Create since you cannot select your own Affinity Group or Network there.
Select the Windows Server 2012 Datacenter operating system
Enter a machine name, username and password.
Note: You'll notice that "admin" and "administrator" are not allowed. This is to help secure your Virtual Machine from script kiddies and "hackers" that might try sniffing out an RDP connection to your hosted VM's and then brute force their way in using a known username and random password guesses. I've heard first hand experiences of RDP session to Azure VM's being hijacked because they were using the "Administrator" account (back when that was allowed in the pre-release days) and they happened to be using a well-known demonstration password. So do yourself a favor and pick something obscure and secure!
Leave the default "Standalone Virtual Machine" enter the DNS Name of the guest OS (typically the same as the Machine Name) and use Auto-generated storage. Select the Virtual Network that you created earlier and it will then show and allow you to select the Subnet.
Leave the Availability Set at (None) and hit the check to finish.
The deployment of the VM will only take a few minutes to complete but it'll boot up and be ready to go shortly.
Once the machine is built, open its Dashboard and scroll down to take note of the Internal IP Address. This IP address will be assigned by a DHCP Lease from your Azure Subnet and will be permanently assigned to this Virtual machine. So while you cannot set a static IP, the one it gets will be the one it always has for the life of the VM.
You could also click the Connect icon to establish a Remote Desktop connection to this VM, then allow PING through the Firewall so you can easily test connectivity to it from the corpnet.
Next Steps and References
Now that you have Azure Networking all setup and even have a Virtual Machine to test with, it's time to set up the Corpnet VPN for the site-to-site tunnel. I cover that in a separate article below.
Site-to-Azure VPN using Windows Server 2012 RRAS
Finally, I am not going to pretend that I just figured this out on my own because I had quite a bit of help. First, fellow MVP Richard Hicks who's great article on establishing a Site-to-Azure VPN using Threat Management Gateway (TMG) 2010 does a great job of covering the Azure side of the setup and I found it particularly helpful. Then Morgan Simonsen who showed us how to establish a Site-to-Azure VPN by using Windows Server 2008 R2 RRAS and helped clarify for me how the subnets in Azure should be defined. I've largely adapted Morgan's instructions to work with Windows Server 2012 in the next article.