Monday, August 4, 2014

Implementing a Windows Azure Site-To-Site VPN

Hi everyone! I'm back! The past few months have seen an increase in projects here at Intelligent Partnerships so I have been shouldering some very challenging projects involving some very complex integrations. Thank goodness for eOne Business Solutions' SmartConnect and SmartPost products which have made for some very happy customers and some extremely robust integrations. In addition, I've been working on quite a bit of customizations migration from Visual Basic for Applications (VBA) to some cool hybrid solutions using Microsoft Dexterity and Visual Studio Tools (VST) for Microsoft Dynamics GP. If you remember, I was one of the pioneers of the technique to replace VBA customizations for hybrid Modifier and Visual Studio Tools. You can read more about this technique in the articles:

Hybrid development for the Managed Code developer
Hybrid development for the Managed Code developer (cont.)


Well, today I wanted to talk about Microsoft Azure Virtual Networks and specifically, the steps needed to setup a Site-to-Site VPN between your Windows Azure virtual network and your Local Area Network.

As you may recall from previous articles I've written on the subject of deploying Microsoft Dynamics GP on Windows Azure, a pre-requisite step before provisioning the VMs that will host SQL Server and your Microsoft Dynamics GP application is to provision and configure a Virtual Network, to be used to communicate the VMs. Also, if you are not going to have your Azure virtual network talk to your on premise LAN, chances are you also need to provision a VM to run Active Directory Services and Domain Name System (DNS) for name resolution - I guess, the typical networking stuff.

As with everything else, life is never this ideal, and most organizations have an on premise AD DC and DNS already in place, so the question is "Why can't we simply use Azure as an extension of our network without having to provision these additional services?" The answer is, of course, you can!

To make the setup process happen smoothly, you must first have the following information at hand:

1. IP address and name of your DNS server
2. Internet facing address of your VPN server or appliance
3. Address space and subnet masks for your local area network (in layman's terms, the range of IPs covered by your TCP/IP network)
4. Optional: Address space you want to use to setup your Azure virtual network.
5. An AD account with privileges to join computers to the domain

To get started, logon to the Windows Azure management portal (http://manage.windowsazure.com). Once in the management portal follow these steps:

1. The first task at hand is to identify our on premise network. Click on the Network Services and Local Network to define your on premise network. Once on the page, click on Add a Local Network.


On premise Network (LAN) setup

2. For this example, we will call the network CONTOSO-ONPREM. You will be asked to enter the public IP address for the VPN. For this example, our CONTOSO-ONPREM network's can be reached at 200.100.50.1. Click the checkmark to proceed to the next screen.

LAN details

Note that this is simply an Azure identifier for your on premise network and not necessarily the actual physical name of it.

3. Now, you must define the range of valid IPs of your on premise LAN. Particularly important here is to know the starting IP address of the on premise network and the Classless Inter-Domain Routing (CIDR) method use for IP address allocation.

Address space

We will assume the CONTOSO-ONPREM routing prefix is 192.168.1.1 and that the usable address range is anywhere from 192.168.1.0 to 192.168.1.255 which gives us a subnet mask of 255.255.255.0 (or 24 "1" bits). Please consult with your on premise network administrator if unsure.

4. Once the on premise network has been defined, you can proceed to register the DNS server for by clicking on the DNS Servers option or clicking the +NEW action button on the lower left corner of the portal.

DNS Server registration

In our example, the CONTOSO-ONPREM DNS server can be found at 192.168.1.20. My preference is simply to assign the FQDN name of the DNS server, though, again, this is just used in Azure to identify the object and rather not necessarily related to the domain name of the machine.

5. Provision virtual network. For our example, we will call this network CONTOSO-AZURE.


CONTOSO-AZURE network provisioning
We can the click next to continue. In the next page of the network provisioning, you will be asked to identify the DNS server and establish the VPN connection to the on premise network.


Azure does a pretty cool job at showing a graphical representation of what you are configuring. In the next page, you can pretty much setup your address spaces and subnet masks. However you must add a subnet mask for your Azure gateway, by clicking the Add Subnet button.



For the purpose of our example, our Gateway IP address will be 10.32.0.0.

Click ok to continue.

6. Azure will now provision the network and make the setup based on the choices you selected. Once the network is provisioned, you can now go to the Dashboard and should see the following:


7. Next steps now involve setting up the VPN tunnel on your firewall to communicate to the Azure gateway.  For this you have a choice of downloading a number of ready to go VPN device scripts (supported devices include Cisco, Juniper, and software-based as Microsoft's). If you cannot find your specific device, it's always good to do a search over the Internet as someone has probably already figured out some configuration for the specific model you have. Important as well is to record the Azure network key, which you will need when setting your VPN.

Once you have established connectivity with your on premise VPN, you can begin provisioning your VMs, making sure you select your virtual network in the process.

Hopefully you found this article useful now that Azure is becoming more and more a choice for hosting Microsoft Dynamics GP.

MG.-
Mariano Gomez, MVP
Intelligent Partnerships, LLC
http://www.IntelligentPartnerships.com

No comments: