In the last article, we looked at using point-to-site to connect individual computers to your virtual network (VNet) in Azure, which works well for intermittent remote management or for developers to get to their VMs. A more permanent connection is needed for a VNet to be part of your infrastructure as a branch office. For some time, your only option was site-to-site.

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

Latest posts by Paul Schnackenburg (see all)

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.

Specify your local network details

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.

Virtual Network Adress Spaces

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

Connections for the site-to-site and one point-to-site client

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.

ExpressRoute ^

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.

Conclusion ^

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.

Win the monthly 4sysops member prize for IT pros


Related Posts

  1. hp 3 years ago

    Hi Paul,
    Great Article.
    One piece impresses me a lot.
    "Recently, however, the capability to have several on-premises locations connect to more than one VNet in different locations became available."
    Segregating my VNETs will give me more flexibility wrt management, billing and security with in my subscription. But doing so, I have to create virtual gateways for each VNET, requireing communication with my On Premise servers. (I would be charged for each hour where each gateway is up).
    would these new changes mentioned by you provide me the facility to manage my Premise to (multiple) VNET communications with a single Azure Gateway?



  2. Thomas Curtis 3 years ago

    I liked the article. It helped quite a bit. However it does not answer a question that I have run into. Is it possible to get an Azure VPN client, say a laptop, to connect to an OnPremise server that is connected to the Azure VNet via a Site-To-Site link. The On Premise server can connect to a cloud server in the VNet and the laptop can communicate with the same server but I cannot get from the laptop to the OnPremise. Thoughts?


  3. Paul Schnackenburg 3 years ago

    Hi Thomas,

    Not sure I understand your question correctly but with a Site to Site configuration it's up to you to configure your on-premises router infrastructure to understand how the routing is set up. In your question you say that the laptop connect to the on premises server but then you say it can't connect to it?

    Hope that helps.


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account