If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the first part in this article series please go to Azure Networking and Security (Part 1).
Introduction
In part 1 of this series, we began the discussion of Azure networking security by talking about the fundamentals of on-premises to Azure Virtual Network connectivity. We covered the first two methods that you can use to connect your on-premises network to Azure – a remote access VPN client connection and a site to site VPN connection. For details about those two connection types, check out that article.
The advantages of dedicated WAN links
The final method of connectivity that’s available to you for connecting your on-premises network to an Azure Virtual Network is a dedicated WAN link. Most of us “old time” IT pros are familiar with dedicated WAN links; we’ve been using them for years. There are a number of availability, security and performance advantages to using dedicated WAN links:
- Dedicated WAN links aren’t dependent on the Internet. These are dedicated point to point connections between your on-premises network and the service provider’s network. This insures a much higher level of availability than anything you might use that’s dependent on Internet connectivity.
- Dedicated WAN links don’t run over a “shared” infrastructure. In other words, your connections between your on-premises network and the service provider network aren’t carrying traffic for multiple customers. This means the dedicated WAN link is also more secure than any over-the-Internet type of connectivity solution.
- Dedicated WAN links can be (if you choose to pay for it) much more performant than Internet dependent connectivity solutions. The level of performance is determined by the agreements you establish with your telco and the arrangements that the service provider has made with the telco, thus there is the potential for much faster performance.
If you’re really serious about extending your datacenter into a cloud service provider’s network, then you should think about going the route of a dedicated WAN link. If you land in the Microsoft cloud world, that route is going to be ExpressRoute.
How ExpressRoute works
ExpressRoute provides two types of connections that link your on-premises network to an Azure Virtual Network:
- Links via a network service provider – these use Multiprotocol Label Switching (MPLS) connections to link your site directly to the Azure Virtual Network.
- Links via an Exchange provider – these links include an initial connection to the Exchange Provider’s network, which in turn is connected to the Azure Virtual Network.
Whether you go with an Exchange Provider or a network service provider is a decision that depends to a great extent on your current telco relationships and the bandwidth requirements you’ll need as part of your architectural design. This is definitely not something you just want to “try out.” You need to take the planning and design process very seriously before you make an investment in ExpressRoute.
Network service provider connections are going to top out at around 1 Gbps. If you need more bandwidth than that (and if you’re serious about datacenter extension into the cloud, you will), then you can go with connections through Exchange Providers, where bandwidth tops out at around 10 Gbps.
You can find more information about ExpressRoute over here.
Securing ExpressRoute connections
One thing that you won’t find at the link is any discussion of security. Fortunately, security isn’t a major problem with dedicated WAN links in comparison to VPN based, over-the-Internet connections that traverse a public network. Because the connections between your on-premises network and the Azure Virtual Network through a dedicated WAN link are dedicated to your organization, requirements for encrypting the data stream are not quite as universal.
That is not to say that network security considerations go out the door when using a dedicated WAN link like ExpressRoute. In most cases, you’ll most likely want to use the same network security methods that you’ve employed in your on-premises network. For example, if you use IPsec server and domain isolation on your on-premises network, you should extend those security policies to all endpoints you have on your Azure Virtual Network.
Constraints and caveats
There are a number of constraints introduced with the ExpressRoute connection to the Azure Virtual Network, but they are similar to those you’ll encounter with most dedicated WAN link solutions. For example, while the connection might provide what appears to be a layer 2 connection between your on-premises network and the Azure Virtual Network, that’s not the case. These are actually layer 3 connections, which means that layer 2 technologies such as 802.1q VLAN tagging aren’t going to work, so you’ll need to take this into account when designing your solution.
Network access controls are important. You need to ask yourself some basic questions before entering into a design exercise that includes the ExpressRoute connection:
- Do you trust that the network or exchange service provider is able to adequately isolate your dedicated WAN link communications from intruders?
- Do you trust that your cloud service provider is able to isolate and secure the virtual network so that it’s safe from intrusion, both from the cloud service provider itself and from an external intruder?
- Do you want to allow all traffic inbound and outbound through the on-premises side of the dedicated WAN link? If not, do you understand your network traffic profile so that you can define which connections can be initiated both into and out of your on-premises network through the ExpressRoute connection?
There are no right or wrong answers to the above questions. Your answers will be based on the security requirements for your organization. Some organizations are relatively lax regarding security and are so because the data traversing the WAN link isn’t of high business impact. Other organizations are going to be very security aware and implement strong controls, because they plan on allowing high business impact information to traverse the link.
You also need to consider the implications of the type of network connectivity you allow inbound to the Azure Virtual Network itself. Here are some example scenarios:
- Inbound from the Internet
- Inbound from the on-premises network
- Inbound from the Internet via the on-premises network
- Inbound from the Internet via a VPN connection to the on-premises network
Inbound from the Internet
In this scenario, you allow inbound connections into your Azure Virtual Network from Internet located devices. You might do this if you want to create a DMZ on your Azure Virtual Network that is similar to your on-premises DMZ setup. In fact, you might consider moving your on-premises DMZ to an Azure Virtual Network, and then using Network Security Groups (which we’ll talk about later) to control which traffic can move from your Azure-located DMZ back into your on-premises network. As you’ll find out later, you can use Azure Network Security Groups to control traffic between subnets on your Azure Virtual Network and between subnets on your Azure Virtual Network and your on-premises network.
Inbound from the on-premises network
After connecting your on-premises network to an Azure Virtual Network using ExpressRoute, which traffic will you allow inbound from on-premises to the Azure Virtual Network? In order words, who and what devices are allowed to initiate new connections from the on-premises network to the Azure Virtual Network?
Management traffic is going to need to be allowed, unless you want to loop out through your on-premises Internet connection to get into your Azure Virtual Network for management purposes (not many people will want to do this, but it is possible).
What about traffic from on-premises devices that need to access services hosted on the Azure Virtual Network?
For example, suppose you are hosting a line of business application on your Azure Virtual Network. The front-end web server is in a DMZ subnet in the Azure Virtual Network and the business logic server is also located on the Azure Virtual Network (but not in the DMZ; the business logic server is located on a subnet separate from the DMZ subnet, but still within the same Azure Virtual Network). The database tier is located on-premises. This is a typical hybrid application design.
On-premises clients in this scenario have at least two potential ways to reach this line of business application:
- They can initiate connections to the front end web server by going out through the corporate firewall to the Internet, and reach the front-end web servers over the Internet.
- Alternatively, these on-premises clients can bypass the Internet and connect to the front-end web servers by going through the on-premises network, through the on-premises side of the ExpressRoute gateway, and then through the Azure Virtual Network to the DMZ subnet on which you placed your front-end web servers.
Both of these options work. But which one would work best for you? Consider the following:
- Client connections that go over the Internet:
- Consume Internet bandwidth
- Consume on-premises network bandwidth
- Will go through the established corporate firewall and/or proxy
- Are potentially exposed to compromise over the Internet
- Are subject to Internet specific availability constraints
- Client connections that go over the ExpressRoute connection:
- Consume dedicated WAN link bandwidth
- Consume on-premises bandwidth
- Will traverse the on-premises gateway to ExpressRoute
- Will generate costs due to response traffic from the Azure Virtual Network to the on-premises network
- Are less likely to be compromised compared to the over the Internet option
- Provide higher availability related to hard-coded SLAs by the network/exchange and cloud service provider
As you can see, even in this simple scenario of on-premises client access to a line of business application that’s situated in an Azure Virtual Network has a number of design considerations that need to be addressed. This is just a gentle reminder that cloud isn’t “set it and forget it” and you need to keep your thinking cap on at all times.
Summary
In this article, we discussed ExpressRoute, which allows you to create a dedicated WAN link connection to an Azure Virtual Network. ExpressRoute is the way that most enterprise organizations are going to connect their on-premises network to an Azure Virtual Network to extend their data centers. ExpressRoute has many advantages over remote access and site to site VPN connections in the areas of availability, reliability, security and performance. We then began a discussion of some of the security issues that you’ll need to consider, starting with some inbound access control scenarios. In the next article, we’ll continue the discussion on inbound access scenarios, and then talk about how you can create security zones with Network Security Groups. See you then!
If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the first part in this article series please go to Azure Networking and Security (Part 1).
