Latest posts by Paul Schnackenburg (see all)
- Microsoft Ignite 2017 Australia - Mon, Mar 6 2017
- Storage Spaces Direct (S2D) - Part 2: setup and monitoring - Tue, Jan 24 2017
- Storage Spaces Direct (S2D) - Part 1: features and fault tolerance - Mon, Jan 23 2017
The limitations of VPN technologies over the public Internet are well known to network engineers and include latency and unpredictable performance. Microsoft recently introduced ExpressRoute, which is essentially a direct connection from your network to Azure (similar to Direct Connect for AWS).
Planning Azure site-to-site VPN ^
If your company is just dipping its toes into using Azure, if low-latency/high-bandwidth hybrid applications aren’t on the agenda, or if you’re in the many locations around the world where ExpressRoute isn’t available yet, site-to-site is your friend.
Your first choice is what device is going to be the local endpoint; you can use a RRAS server (Windows Server 2012/2012R2) or a hardware appliance. The list of devices is quite comprehensive, but even if your particular router/VPN box isn’t on the list it should work as long as it supports IKE/IPSec-based VPN. Note the difference between static and dynamic routing, where the former doesn’t support multi-site, VNet-to-VNet (see below), or point-to-site functionality. Also note that preconfigured configuration scripts exist for some device models, whereas others come with instructions that you have to follow.
Setting up Azure site-to-site VPN ^
I prefer to create the local (on-premises) network first, so select Networks in the console, and then select New and Add a local network. You have to define the fixed public IP address of your VPN device and the IP address ranges of your on-premises networks.
You can define your local network either during the creation of a VNet or beforehand.
Once you have this defined, go back to Networks, New, and Custom Create, give the VNet a name, and choose your region (any VMs you want to house in this VNet need to be in the same region). Specify one or more DNS servers if your needs can’t be met by Azure’s built-in name resolution, and select the box for site-to-site VPN. You also need to select the local network you created previously.
Make sure there are no overlapping IP networks in your on-premises and VNet configuration.
Once the configuration of the VNet is complete and you go back to the Dashboard, it’ll show up as disconnected. Click Create a Gateway, if this hasn’t been done for this VNet yet; this could take up to 15 minutes. When this is completed, there will be a link to download a VPN script in the Quick Glance section on the right. Here, you can choose between Cisco, Juniper, and Microsoft, with several device models for each of the first two and RRAS for Microsoft.
In my test, I selected RRAS for Windows Server 2012 R2. I had to change the extension of the VpnDeviceScript.cfg file that I downloaded to .ps1, and I also right-clicked the file, selected Properties, and then unblocked it. Note that the script will install and configure RRAS, so all you have to supply is a Windows Server 2012/2012R2 machine (virtual or physical). The RRAS machine can be set up with one or two NICs, where the latter option is more flexible. This is also not just a generic script; it already has all the right values for your particular VNet and configuration.
Open an administrative PowerShell prompt, change to the folder where the script was saved, and change your security by typing:
Then, run the script by typing:
This will install and configure RRAS to connect to Azure. The red resulting error at the end is normal due to timeouts. Open the RRAS console. You should see a network interface with the IP address of your connected gateway in Azure.
Officially, the RRAS server or device can’t be behind a NAT firewall. However, doing so is possible for testing purposes as long as you forward the following ports to your device or RRAS server:
- UDP 500
- UDP 4500
- UDP 1701
Here, we can see connections for the site-to-site and one point-to-site client.
Cross-premises and VNet-to-VNet connections ^
When first released, the site-to-site connection could only be from one on-premises network to a single VNet. Recently, however, the capability to have several on-premises locations connect to more than one VNet in different locations became available. This currently requires manual editing of the NetworkConfig.xml file, as well as a good working knowledge of VPN configuration as no script for device configuration is available. Also fairly recent is the capability to link VNets together between datacenters and between subscriptions; this can also be combined with multi-site VPN. The one piece missing from this puzzle today to make Azure truly enterprise-ready is Border Gateway Protocol (BGP) support, but this is coming, as is support for WAN optimization.
Recently released to General Availability, this feature offers security (your traffic doesn’t go over the public Internet) and performance (low latency, high throughput). There are two flavors: Exchange Provider, with a max bandwidth of 10 Gbps, or Network Service Provider (MPLS), with a max of 1 Gbps. Several providers and options are available; depending on your geographical location, different service levels are available. The steps to set up ExpressRoute are covered in the links above.
Fixed VIP ^
The public virtual IP address (VIP) for a cloud service can change if you stop and deallocate all VMs running in it. A new option is that you can use the new New-AzureReservedIP cmdlet to set the IP address as fixed, which will help when a simple CName record isn’t useful—such as when using IP addresses in a firewall configuration. Note that this still doesn’t let you choose the IP address; it merely ensures that it stays the same even if you shut down the VMs that use that address.
Troubleshooting Azure networking ^
Apart from the always useful PING, there’s an excellent tool for troubleshooting networking, including Azure connectivity, called PsPing in the SYSinternals toolbox. It can be used for TCP and ICMP pinging, along with testing of bandwidth and latency. The latter is crucial in public cloud deployments.
Once you get past the initial testing of Azure IaaS, where you just create a few VMs to see how it all works, networking becomes crucial. The real test of any hybrid cloud setup relies on good network configuration. As you’ve seen, setting up a VNet with site-to-site VPN is fairly easy.