This is the 38th in our series of guest posts by Microsoft Most Valued Professionals (MVPs). You can click the “MVPs” tag in the right column of our blog to see all the articles.
Since the early 1990s, Microsoft has recognized technology champions around the world with the MVP Award. MVPs freely share their knowledge, real-world experience, and impartial and objective feedback to help people enhance the way they use technology. Of the millions of individuals who participate in technology communities, around 4,000 are recognized as Microsoft MVPs. You can read more original MVP-authored content on the Microsoft MVP Award Program Blog.
This post is by Enterprise Security MVP Richard Hicks. Thanks, Richard!
If you are an IT professional, no doubt you have a lab environment to perform development, pre-production testing, quality assurance (QA), and many other things I’m sure. With the introduction of Windows Azure Infrastructure-as-a-Service (IaaS), IT pros can now leverage the flexibility and near-limitless capacity of the public cloud to serve this purpose much more effectively. However, lab environments often require access to resources and data not easily migrated to the cloud. In addition, if your testing requires specialized hardware configurations (e.g. multiple network adapters, hardware security modules, physical HBAs, etc.) then moving your entire lab to the cloud won’t be possible. You can, however, extend your lab environment to include resources in Windows Azure to provide additional capacity as needed. In this article I’ll demonstrate how you can use the site-to-site VPN feature of the Routing and Remote Access (RRAS) role in Windows Server 2012 R2 to serve as a gateway to enable cross-premises network connectivity between your on-premises lab network and your Windows Azure virtual networks.
Configuring a Windows Server 2012 R2 system to serve as a gateway to Windows Azure virtual networks comes with some unique requirements. To start, this server must have two network interfaces; one internal and one external. The external network interface must be assigned a public IPv4 address and cannot be located behind a Network Address Translation (NAT) device. Also, configuring a multi-homed server requires that special attention be paid to network interface configuration. For more details on this, see my article Network Interface Configuration for Multihomed Windows Server 2012 DirectAccess Servers, which also applies to site-to-site VPN gateway servers. The internal network interface will be assigned a private IP address, which for simplicity can also be used as the default gateway for the lab network. However, if your lab network requires access to other internal networks or the public Internet, then routing to Windows Azure virtual networks will have to be configured to use the gateway’s internal network interface as the next hop for those remote subnets.
In the Windows Azure management console, select Networks from the navigation tree and then click Create a Virtual Network. Give the network a descriptive name, select an appropriate region, provide a name for the new affinity group, and choose a subscription to associate this network with.
Provide the names and IP addresses of any DNS servers you want the virtual machines assigned to this network to use. To enable the joining of machines on this network to our on-premises Active Directory, provide the names and IP addresses accordingly. Select the option to Configure site-to-site VPN. Optionally you can also choose to Configure point-to-site VPN, which will allow you to enable client-based remote access VPN to the virtual network for remote users.
Provide a name for the site-to-site connection, and for the VPN Device IP Address, enter the public IPv4 address assigned to the external network interface of the server. Enter the IP address space used by your on-premises network. For example, my home lab consists of a single IPv4 subnet of 172.16.1.0/24, which I’ve entered here.
Choose the address space to be used in your Windows Azure virtual networks. You can accept the defaults, which establishes a 10.0.0.0/8 network and creates a single subnet 10.0.0.0/11. Alternatively you can specify any of the RFC 1918 private IPv4 networks and create subnets as you wish. I’ve chosen to use the 192.168.0.0/16 network and create a single subnet of 192.168.0.0/24. Once you’ve established your network address space and created subnets, be sure to click Add Gateway Subnet to create the dedicated gateway subnet required to establish site-to-site VPN connectivity.
Once the virtual network has been created, click on the new virtual network, and then click Create Gateway at the bottom of the screen and choose Dynamic Routing. It may take several minutes for the gateway to be created, so be patient. Once the gateway has been provisioned, make note of the Gateway IP Address, and then click Manage Key at the bottom of the screen. Copy the shared key, as it will be used for the site-to-site VPN configuration on the Windows Server 2012 R2 server.
Now that we’ve created our Windows Azure virtual network and site-to-site VPN gateway, we can proceed with configuring our on-premises Windows Server 2012 R2 server for Windows Azure connectivity. We’ll begin by installing the Routing and Remote Access Service (RRAS). Open an elevated PowerShell window and enter the following command:
Install-WindowsFeature routing -IncludeManagementTools
Once complete we’ll install the site-to-site VPN feature and create a connection to our Windows Azure virtual network using the following PowerShell commands. The $peer variable is the Windows Azure gateway IP address, and the $vnet variable corresponds to the network address space the Windows Azure virtual network has been assigned. In addition, the $psk variable is the pre-shared key obtained previously.
$vnet = "192.168.0.0/16:100"
$psk = "eTO6FHnbVDCMGuPtx7eDcDEIOZJ7dCVR"
Install-RemoteAccess -VpnType VpnS2S
Add-VpnS2SInterface -Name $connection -Protocol IKEv2 -AuthenticationMethod PSKOnly -NumberOfTries 5 -ResponderAuthenticationMethod PSKOnly -Destination $peer -IPv4Subnet $vnet -SharedSecret $psk -Persistent
Set-VpnServerIPsecConfiguration -EncryptionType MaximumEncryption
Now we’ll restart the Remote Access service and establish our site-to-site VPN connection to Windows Azure.
Once the RemoteAccess service has been restarted we’ll initiate the site-to-site VPN connection to Windows Azure.
Connect-VpnS2SInterface -Name $connection
You can also view the status of the connection using the following PowerShell command:
Get-VpnS2SInterface -Name $connection
Finally, to reduce the possibility of fragmentation for cross-premises network traffic we’ll change the Maximum Transmission Unit (MTU) on the server’s external network interface using the following Netsh command:
netsh interface ipv4 set interface external mtu=1350
Provision Window Azure Virtual Machines
When you deploy a Windows Azure virtual machine, now you'll notice that you can specify to which virtual network and subnet you want the virtual machine to reside in.
Once you’ve provisioned the Window Azure virtual machine you will be able to connect to the host via its internal IP address. You can now join these Windows Azure virtual machines to the domain and install applications and services as required.
Harnessing the power of the public cloud has never been easier. Windows Azure virtual machines can provide an efficient way to extend the capabilities available in our on-premises lab environments. Leveraging Windows Server 2012 R2’s remote access capabilities provides an easy and cost-effective way to enable cross-premises network connectivity to Windows Azure virtual networks. If you haven’t started using Windows Azure yet, get started today! You can sign up for a free trial and start taking advantage of this wonderful resource immediately.
I'm curious, why didn't you use the PowerShell script that Azure automatically produces to configure your RRAS Server?