More and more people realize that Microsoft Azure can be a huge benefit in their day to day business. The scalability of services and speed with which you can run your business on a global scale is unprescedented to anything you would be able to accomplish in your own datacenter.
The Azure web interface looks straight-forward enough, but after working with it for a few days, weeks, months or after following one of my Azure classes, people soon realize that Azure really consists out of a lot of “moving parts”. This blogpost I’ll focus on all moving parts surrounding a Virtual Machine in Azure. Lots of readers will surely think:”Come on, it’s not that different from an on-prem VM, is it?” I could just give you the answer right away, but that would make for a really short blog post, wouldn’t it?
Part 4: Go Hybrid
Welcome back at part three of this four-part series. So far we’ve created a Virtual Machine in a very structural way, we’ve created a small design, sized the Virtual Machine to our likings and attached it to a Virtual Network which is future-proof. Now comes the time everybody (hopefully) was waiting for… Let’s go Hybrid!
For a small recap; this where we left off in Part 3; A Virtual Machine with Windows Server 2012 R2, running in Azure. When you’re recreating your own environment according to my posts, don’t forget to shut down your Virtual Machine(s) at the end, or they will incur costs to your Azure (test-) Subscription.
For lots of workloads this already might be enough, just to have an extra environment in Azure. But to unlock the real power of the Microsoft Hybrid Cloud, we want cross-site connectivity. We’ll achieve this through the Virtual Network we’ve created before, and will have to set-up some connectivity settings at our on-premise environment. In this post we’ll use a Cisco ASA 5505 at our datacenter location to terminate the VPN connection from Azure.
Let’s switch back to the “current” portal, http://manage.windowsazure.com. Navigate to the networks section in the left-hand menu.
After that, select the network you’ve created earlier and browse to the “local network” tab. We’re going to define where the Site-to-Site VPN will connect to. For this you’ll need a supported VPN device, a network configuration file and the public IP address of the site you’re connecting to.
When creating a new local network, you will be guided through a Wizard, which will need your public IP address, a name for the concerning location and the local subnets used on-premise.
These screens will look something like these ones:
Now the local network, or the target for our VPN connection is in place, we will need to enable the network to use cross-premises connectivity. In the specified Virtual Network, browse to the “configure” tab.
Double-check your subnet settings done previously and then click on “Connect to the local network” and hit save, this will connect your Virtual Network with your on-prem network (in the WebUI at least). When you switch back to the dashboard page of the network, you’ll find a sight like this
Next step is to create the gateway which will enable network traffic to exit Microsoft Azure, through our soon-to-be private connection. Since the software in my ASA doesn’t support fancy stuff like dynamic routing, I had to go with “Static Routing”. Enable the gateway for this network at the dashboard page of the virtual network, as shown below.
Now, grab a cup of coffee, or maybe two.. This can take a considerable amount of time, I’ve waited for this process to complete for 25-30 minutes at times, so be patient…
When this process completes, our friends over at Microsoft provide us with configuration scripts for three VPN Endpoint providers. On the right-hand side of the screen, you can “Download VPN Device scripts” for Cisco, Juniper of Windows Server 2012 VPN devices.
Choose the appropriate device and OS of that device and download the script. If your device i’sn’t on the preferred device list, you can always check all configuration files .
The configuration of your ASA is straight forward enough, even with the GUI (ASDM). Open the “multiple” command line interface, paste the text from the config file, and commit the configuration change.
<PICS to follow>
Once that command has been processed, you can start to connect Azure to your on-premise location. Click on “connect” at the bottom of the screen, and sit back and wait for the magic to begin. After a few minutes, check back and watch your hybrid network being connected.
The proof (as always) is in the pudding. What I’ve done, is to create another VM, HybridVM1, and joined that one to the domain. Now, for testing purposes (after allowing ICMPv4 in the Windows Firewall), I checked connectivity with a ping… and it works!
I hope with this series I’d been able to shed some more light, on the planned creation of Virtual Machines in Azure, combined with hybrid connectivity between the big Azure Cloud and your on-premise datacenter.