If you would like to read the other parts in this article series please go to:
- Microsoft Azure: The Network Operating System of the Future, Today (Part 1) – Why You Should Care
- Microsoft Azure – The Network Operating System of the Future, Today (Part 2) – Dedicated WAN Connectivity with ExpressRoute
- Microsoft Azure – The Network Operating System of the Future, Today (Part 4) – Multi-Site VPN and VNet-to-VNet Connectivity
Introduction
In the second part of this series, we talked about how you can use ExpressRoute to create a dedicated WAN link between your corporate network and an Azure Virtual Network. ExpressRoute is a great choice for large enterprises that need very high performance and the best possible uptime. Of course, with that kind of over-the-top performance and uptime comes a hefty cost. But if you need it and you can create a compelling business case for ExpressRoute, then it’s definitely the way to go.
What if you don’t need or can’t afford the performance and uptime and cost that go with ExpressRoute? What if you want to extend your on-premises datacenter to the public cloud? There are a number of reasons you might want to do this without having to break the bank with ExpressRoute. We’ve mentioned some of these reasons before, such as taking advantage of the public cloud provider’s elasticity, where you can get the resources you need when you need them and then release them when you no longer need them. Or maybe you just want to use the public cloud provider to host a virtual datacenter for you, where you can put resources that you can fall back on in the event of a disaster.
An alternative to ExpressRoute
Whatever your reasons, the good news is that there is an alternative to ExpressRoute. That alternative is site-to-site VPN. The Microsoft site-to-site VPN capability has come a long way since Windows 2000 Server. As a matter of fact, it has come such a long way that Azure now provides you with an RRAS server to connect your on-premises VPN gateway to create a site-to-site VPN connection.
Most of you probably already know what a site-to-site VPN is, but just as a refresher, a site-to-site VPN is a virtual WAN link between your on-premises datacenter and a datacenter somewhere else. It’s similar to a remote access VPN client connection, with one big difference. A remote access VPN client connection connects one computer to a network over the Internet. Almost all of us have used remote access VPN client connections at one time or another to connect from our home computers or mobile devices to our work networks.
The big difference between a remote access VPN client connection and a site-to-site VPN connection is that instead of connecting one client computer to a network, the site-to-site VPN connection connects entire networks to each other through a virtual network connection. This virtual network connection is also similar in practice to a dedicated WAN link, with the big difference between them being that a dedicated WAN link represents a dedicated physical connection between your corporate network and another network, and the site-to-site connection represents a virtual connection that uses the shared Internet to connect the sites.
Azure site to site VPN – then and now
Azure has supported site to site VPN networks for some time, so the site-to-site connectivity option isn’t something new. What is new is the ability to connect multiple sites to a single Azure Virtual Network. This was a big problem in the past for organizations that had more than one on-premises site.
The single site problem
Imagine that your company has five locations throughout the world that you want to be able to connect to an Azure Virtual Network and the resources that are located within that Azure Virtual Network. One of the sites would host the VPN gateway that connected the corporate network to the Azure Virtual Network. The question then is how do the other sites connect to the resources on that Azure Virtual Network? Ideally, they would be able to connect through a local site-to-site VPN gateway.
The problem with that, in the past, was that an Azure Virtual Network would only accept connections from one site-to-site gateway. Because of that, the sites that didn’t host the corporate site-to-site VPN gateway had to route through whatever existing corporate network connections were available to reach the corporate site-to-site VPN gateway in order to access corporate resources that were hosted on an Azure Virtual Network. This generates a great deal of internal traffic on the corporate links that should have just gone to the Azure Virtual Network directly over the Internet.
The multiple site solution: What you need to know
With the introduction of multiple site-to-site VPN connections that are allowed to connect to a single Azure Virtual Network, we no longer have to take a hit on our own local network performance. However, before you embark on a planning and subsequent design exercise based on Azure site-to-site VPN, there are a few things you need to know and think about in addressing this capability:
- Multi-site site-to-site VPN configuration can only be done by editing the network configuration file that drives the configuration of an Azure Virtual Network. That means you can’t use the Azure Portal to configure the multi-site site-to-site VPN connections and it also means you can’t use PowerShell. Also, if you try to make any changes to the Azure Virtual Network in the portal, it’s likely to render your multi-site site-to-site VPN connection unusable. You need to know this before you deploy and just as importantly, anyone else who might make changes to your virtual networks needs to know about this too.
- In order to use multi-site site-to-site VPN, the VPN gateways you use on-premises to connect to the Azure Virtual Network need to support dynamic routing for the VPN connection. What does that mean? As so many say about their Facebook relationships, it’s complicated. If you check this link, there is a definition of sorts regarding dynamic routing VPN gateways, but it doesn’t really provide a lot of information in terms of what the real differences are. This information from Wikipedia might give you a bit more insight.
- You have to use public IP addresses for your on-premises gateway. Ouch! Not only that, but they have to be IPv4 public addresses, and that’s something that we’ve technically run out of. Whether or not this is going to be a big problem for you depends on what your network security policies are for edge devices. Some organizations demand that network edge devices be dedicated to firewall duty, and VPN gateways need to be placed behind the edge firewalls. In most cases, that means you need to NAT to your VPN gateway. If so, a site-to-site VPN connection to an Azure Virtual Network isn’t going to work for you. However, you can still put public IPv4 addresses behind the firewall and have the firewall route to the public IPv4 address of the site-to-site VPN gateway. This is feasible if you have a surfeit of public addresses in your organization.
- One of the great things about configuring site-to-site VPNs with Azure is that Microsoft provides a huge number of configuration scripts that you can use to configure your on-premises hardware. This is a great time and money saver, because if you don’t have the expertise to configure the site-to-site VPN, no problem! You can find these scripts here. That’s the good news. The bad news is that if you want to do the same thing with your multi-site site-to-site VPN connections, you’re out of luck. You’re going to either have to have in-house expertise with your VPN gateway, or hire someone who’s knowledgeable about your model of VPN gateway to configure the multi-site site-to-site VPN connections for you.
- Keep in mind that the multi-site site-to-site VPN configuration is really only an extension of the existing Azure site-to-site VPN capability. That means you need to get up to speed on the core site-to-site VPN offering before you leap in. If you haven’t done that yet, be sure to read the Configuring a site-to-site VPN in the Management Portal article. Also, be sure to include Virtual Network Overview because it will provide you with some key considerations around device selection (for the VPN gateway), IP addressing schemes, name resolutions issues and more that must be addressed before you complete the design of your site-to-site solution.
The Performance Question
Now I know some of you have been asking about performance. We talked a lot about the enhanced performance you get with the ExpressRoute dedicated WAN link solution, and that was pretty impressive. However, I’m afraid we can’t provide any definitive information about site-to-site VPN performance characteristics. We’ve seen some past videos from TechEd that stated that, for all practical purposes, the top speed you could get on the site-to-site VPN was about 80Mbps. This was primarily due to the fact that there were issues related to pinning all the network traffic to a single virtual processor. From what we understand, Windows Server 2012 R2 fixes this issue. However, what we don’t know is whether the Azure infrastructure has been upgraded to Windows Server 2012 R2 yet, and if it has, whether or not this capability has been extended to customer deployments. When this information becomes available, we’ll make sure to get it out to you.
Summary
In this article, we moved our attention away from the dedicated WAN link to the virtual WAN link. If you don’t want to incur the costs, or don’t need the performance and reliability of a dedicated WAN link, you can connect your on-premises network to an Azure Virtual Network using a site-to-site VPN, so we talked about some of the things you need to know about site-to-site VPNs and issues that you need to know about and consider before you plan and design a site-to-site VPN between your on-premises networks and an Azure Virtual Network. Thanks! –Tom and Deb.
If you would like to read the other parts in this article series please go to:
- Microsoft Azure: The Network Operating System of the Future, Today (Part 1) – Why You Should Care
- Microsoft Azure – The Network Operating System of the Future, Today (Part 2) – Dedicated WAN Connectivity with ExpressRoute
- Microsoft Azure – The Network Operating System of the Future, Today (Part 4) – Multi-Site VPN and VNet-to-VNet Connectivity
