If you would like to read the next part of this article series please go to Azure Networking and Security (Part 2).
Introduction
With cloud computing, and especially with Microsoft Azure rising into the consciousness of many IT organizations that formerly would have never considered using any kind of public cloud service, many of us are thinking about how we might be able to take advantage of public cloud services. More people are thinking about taking advantage of public cloud service now because cloud computing has moved past the hype stage, and most people in the industry know and understand the new cloud computing paradigm. It only took about 8 years, but better late than never.
One of the things that helped IT organizations really start to consider public cloud computing was that they realized that when someone says “moving to the cloud,” it really doesn’t have to mean “moving.” Instead of moving IT assets into a public cloud, they can actually extend their datacenters into the public cloud. There are a lot of things to recommend this approach, such as potential cost saving due to the fact that you don’t have to buy your own hardware, won’t need to build a new on-premises datacenter, and don’t have to incur the overhead of the typical initial engineering processes that includes the racking and stacking and integration with your current environment from a physical perspective.
Thus, this “moving to the cloud” stuff is really not “moving” to the cloud, it’s more like “extending” into the cloud. Enterprise IT can benefit by extending their current on-premises network into a public cloud. This really isn’t magical or revolutionary when you think about it. We’ve been using co-lo facilities for years. The big difference is that cloud service providers such as Microsoft take care of all the hardware management for you. All you need to do is place your IT assets onto virtual machines within the Azure public cloud environment.
Cloud service models
There are actually a few ways you can take advantage of public cloud services. There’s the SaaS service model, where the cloud service provider hosts the applications for you. An example of that is Office 365. Then there’s PaaS (Platform as Service) where the cloud service provider provides you with operating systems on which you can deploy code, so that you don’t need to manage the hardware or the operating systems, Azure will do that for you. The only thing you need to worry about is management of your code.
The most interesting cloud service model for enterprise IT is IaaS (Infrastructure as a Service). With IaaS, IT shops can put virtual machines into the cloud service provider’s environment in the same way they can put virtual machines on their own on-premises virtualized infrastructure. The big difference between the on-premises and public cloud deployments is that you don’t need to manage the network, compute (server) and storage hardware on which your virtual machines run when you place them into the cloud service provider’s network. With on-premises virtualization, you have to do all that, and deal with the time and expense related to managing that hardware.
Amazing Web Services got a big lead in the cloud service provider market because they focused on IaaS from the start. They realized that enterprise IT was not yet in a position to fully adopt PaaS services. There are a number of reasons for this, including the fact that we’re still in a place where the majority of enterprise organizations are primarily interested in IaaS when it comes to wholesale public cloud service adoption. Microsoft also realized this, and now they have invested a tremendous amount of resources into their Azure Infrastructure Services feature set, all architected and designed to support public cloud IaaS services.
Azure and cross-premises connectivity
Are you an enterprise IT shop interested in Microsoft IaaS? If so, you’re probably curious about the capabilities Azure Infrastructure Services brings to the table and also how you can extend your network into the Azure public cloud. There are many, many features in Azure Infrastructure Services, and you will need to have your architects and designers work together to first understand all the capabilities that Microsoft Azure Infrastructure Services has to offer.
A great place to start is the Microsoft Infrastructure as a Service Foundations Series. That collection of documents provides you with information about everything that Microsoft currently has to offer for both on-premises and public cloud Infrastructure as a Service.
In order to extend your datacenter into the Azure public cloud, you’re going to need network connectivity. There are two types of network connectivity that are relevant here:
- Connectivity between your on-premises network and the Azure public cloud
- Connectivity for virtual machines that are contained within the Azure public cloud
Connecting on-premises resources to Azure
There are several ways you can connect your network resources to the Azure public cloud:
- Remote access VPN client connections (what Azure calls “point to site” connectivity)
- IPsec tunnel mode site to site VPN
- Dedicated WAN links
Remote access VPN client connection
The first option, remote access VPN client connections, doesn’t connect an entire network to the Microsoft Azure public cloud. What it allows you to do is connect to an Azure Virtual Network (which we’ll talk about in a little bit) using a remote access VPN client connection, which enables you to connect individual machines to the Azure Virtual Network. This is good for remote management of virtual machines located on an Azure Virtual Network. The remote access VPN client connection uses the SSTP protocol to connect to the Azure Virtual Network, and it is more secure than using the alternative method, which is RDP, to manage virtual machines located on an Azure Virtual Network.
The reason remote access VPN client connections are more secure than using RDP to connect to virtual machines over the Internet is that with VPN, you must first authenticate the VPN connection before gaining access to the Azure Virtual Network. Only after successfully completing that authentication process will you then be able to connect to the virtual machine.
You will then need to authenticate with the virtual machine. Given that a certificate is required to establish the VPN connection, odds are very low that an attacker will have access to that certificate. This is in contrast to RDP connectivity, where applications such as “password grinders” can potentially compromise virtual machines through password guessing.
With all that said, the remote access VPN client connections are not about connecting your enterprise network to Microsoft Azure; this is about enabling remote access to virtual machines that are contained within Azure Virtual Networks so that you can manage them from individual workstations.
IPsec tunnel mode site to site VPN
The next option, IPsec tunnel mode site to site VPNs, is where the “enterprise to Azure public cloud services” connectivity story begins. Site to site VPNs have been around for a long time. On each side of the connection (the on-premises side and the Azure Virtual Network side) is a “VPN gateway”. A VPN connection is established between the VPN gateways. The connection is made over the public Internet.
The VPN gateway is essentially a router. You have your set of network IDs that are located on your on-premises network, and you’ll have your set of network IDs that are included in the Azure Virtual Network. The routing tables in your on-premises infrastructure will be aware of (either through dynamic routing protocols or through manual edits) the network IDs that are located on the Azure Virtual Network and will be configured to use the IP address on the internal side of the on-premises VPN gateway as the route to the network IDs on the Azure Virtual Network.
The same thing happens on the Azure side. The VPN gateway on the Azure side is aware of the network IDs you have on-premises, and will forward connections to those network IDs through the Azure VPN gateway to your on-premises VPN gateway, which then forwards the connections to the approach routers so that the connections can be established.
In order to make sure that no one can see the communications moving over the site to site VPN, all information crossing the Internet over the site to site VPN is encrypted using the IPsec protocol. This level of encryption helps mitigate security issues related to allowing privileged information to traverse the public Internet. That said, the connections still move over the public Internet, and you will need to determine whether the risk/benefit ratio works for you.
Advantages and disadvantages of site to site VPNs
Site to site VPNs are attractive because they are cost effective. When connecting to an Azure Virtual Network over a site to site VPN, you only pay for traffic leaving the Azure Virtual Network. You don’t have to pay for any traffic moving into the Azure Virtual Network. Site to site VPNs are also popular because they are based on a mature technology that most IT organizations already understand quite well.
The downside of site to site VPNs is that they can be relatively slow and unreliable. Connections between on-premises networks and the Azure Virtual Network depend on Internet connectivity. There are no guarantees when it comes to Internet connectivity. Even if your ISP provides you with Service Level Agreements (SLAs), they cannot be responsible for all points between your POP and the Azure Virtual Network itself. Microsoft does provide you with SLAs too, but then again, the SLAs only apply to networking issues under Microsoft’s control, similar to the situation to the SLAs you have with your local ISP.
The performance issue is another important consideration. The performance levels you’ll see for site to site VPNs vary with the hardware involved. For example, if you use a Cisco ASA 5500 series firewall, you’ll see site to site VPN performance top out at around 250 Mbps. You might think that’s pretty good for Internet connectivity, and it is. But we’re talking about data center extension here, and in that case, 250 Mbps is positively anemic compared to the 10/40 Gbps networks you’ve probably architected on-premises.
The Microsoft Azure VPN gateway can support up to 200 Mbps throughput, if you choose to use the Azure high performance gateway (which is going to cost more than that standard VPN gateway). The standard Azure VPN gateway tops out at around 80 Mbps. With speeds like that, you’re really thinking more branch office computing than enterprise data center extension.
Summary
There are scenarios where site to site VPNs are appropriate based on your organization’s unique security and performance requirements. But for most enterprise grade IT shops, you’re going to need to go the route of the dedicated WAN link. In the next article in this series, we’ll talk about the dedicated WAN link options for connecting your on-premises network to a Microsoft Azure Virtual Network. See you then!
If you would like to read the next part of this article series please go to Azure Networking and Security (Part 2).
