Hybrid Network Infrastructure in Microsoft Azure (Part 3)

If you would like to read the other parts in this article series please go to:


By Tom and Deb Shinder

In part 1 of this series, Deb began the discussion about hybrid network infrastructure with some thoughts about what hybrid clouds are about, and then talked about some of the networking functionality that you get when you adopt Azure Infrastructure Services. There was also an introduction to the Datacenter Extension Reference Architecture Diagram that Tom had put together with Jim Dial and several other people at Microsoft. In part 2 of the series, Tom joined in as co-author and we went over site to site VPNs and point to site VPNs.

We’ll continue the discussion by working our way through the list of network capabilities that are available in Azure at the time this article was written. As a reminder, here is that list:

  • Site to site VPNs
  • Point to Site VPNs
  • Dedicated WAN links
  • Virtual network gateways
  • Azure Virtual Networks
  • Inter-virtual Network connectivity
  • External load balancers
  • Internal load balancers
  • Network Security Groups
  • Virtual machine ACLs
  • Third party proxy firewalls
  • Dual-homed
  • Dedicated public IP addresses
  • Static IP addresses on virtual machines
  • Public addresses on virtual machines
  • DNS

Dedicated WAN Links (ExpressRoute)

There are a couple of methods you can use to connect your on-premises network to an Azure Virtual Network. As discussed in part 2 of this series, one of those options is a site to site VPN. On the up side, site to site VPN are cheap. On the down side, they top off their bandwidth at around 200 Mbps for the high performance site to site VPN option, and 100 Mbps for the non-premium version.

Site to site VPNs are useful if you anticipate only moderate amounts of traffic moving between your on-premises network and your Azure Virtual Network. They could be useful if you only want to use the connection for management traffic, or for management and lightly used on-premises services. However, if you are thinking of actually extending your on-premises infrastructure to Azure, then you’ll want a lot more bandwidth (and reliability).

Think about it: you’ve spent years, maybe decades, fine tuning and optimizing your on-premises networks. You have 10-40-100 Gbps backbones and have latency down to an absolute minimum. Now you want to extend your on-premises network to the cloud. Are you really going to get much use out of a puny 200 Mbps connection for your heavy duty Tier 1 workloads?

Obviously not. But Microsoft does have a very good solution for you and it’s called ExpressRoute. ExpressRoute is a dedicated WAN link that you can use to get both high performance and high reliability. Like any other dedicated WAN link, you get a dedicated circuit between your on-premises network and the Azure Virtual Network. Thus, in addition to the performance and reliability advantages over site to site VPN, you also get greater security, because your communications do not flow over the Internet.

ExpressRoute options

ExpressRoute offers you two slightly different methods you can use to connect to the Azure Virtual Network:

  • Exchange Provider
  • Network Service Provider

Exchange Providers are going to give you the highest bandwidth, serving up bandwidth options from 200 Mbps (blah) up to 10 Gbps (whoot!). Of course, like all things related to the cloud, the more you use, the more you pay. You’ll be paying a lot more for the 10 Gbps connection than you’ll be paying for the 200 Mbps connection.

Note that when you use an Exchange Provider, you’re not directly connecting your on-premises network to the Azure Virtual Network. What you’re actually doing is connecting your network to the Exchange Provider’s network, and then from there, you can route to the Azure Virtual Network.

Network Service Providers allow you to connect to your Azure Virtual Network using MPLS (Multi-Protocol Label Switching). For this reason, you’re not going to get the bandwidth you can get from the Exchange Provider solutions (Exchange Providers top out at 1 Gbps), but then, you’re not going to pay as much, either.

Keep in mind that the decision to use either an Exchange Provider or a Network Service Provider is going to be based on your requirements for security, performance and reliability. Another major consideration as far as which option to choose is going to be based on availability. Depending on your location, you might only have one option available to you.

For more information about ExpressRoute, check out this link

Virtual Network Gateways

When you connect your on-premises network to an Azure Virtual Network, you’re always creating a routed connection. This is nothing new, as many of you are already using hosting providers and connecting to the provider’s network in the same way. In order to establish that routed connection, you’re going to need a router. By the same token, Azure also needs a router to connect to your router.

This is where the Azure Virtual Network Gateway comes in. Not all “gateways” are routers (gateway is a generic term used to represent many different capabilities in IT, generally pertaining to any network device that interfaces with a different network). In the case of the Azure Virtual Gateway, however, it is a router. The Virtual Network Gateway supports both site to site VPNs and ExpressRoute. However, if you have ExpressRoute, you will not be able to use site to site VPNs with a basic gateway (not that you would want to, because your ExpressRoute connection is a lot faster and more reliable).

There are three types of gateways from which you can choose:

  • Basic. With the basic gateway, you have to choose between site to site VPN or ExpressRoute. VPN throughput tops off at 100 Mbps and ExpressRoute goes up to 500 Mbps.
  • Standard. With the standard gateway, you can co-locate your VPN connection and ExpressRoute connection. In this case, you can get up to 1 Gbps on your ExpressRoute connection, but the VPN still tops out at 100 Mbps.
  • Performance. The Performance gateway gets you up to 2 Gbps ExpressRoute bandwidth, and 200 Mbps VPN bandwidth.

Now, you might be asking yourself “hey, I thought I could get up to 10 Gbps on my ExpressRoute connection, so what’s up with that piddley little 2 Gbps?” My answers would be: 1) I wouldn’t call 2 Gbps piddley :), and 2) This maps the top rate for the Network Service Provider connections, which use MPLS, which is a VPN encapsulation technology. I assume that the 2 Gbps support is provided to enable fault tolerance, since the MPLS connection support is limited to 1 Gbps.

Gateway configuration considerations

Gateway configuration isn’t for the timid. The site to site VPNs use IPsec tunnel mode, and you have to make sure that all of your IPsec parameters (such as IKE version, hashing algorithm, SAs, PFS, etc.) are configured correctly. As for configuring ExpressRoute, you’ll need to work with your provider to get the information you need, so configuration, while potentially complex, won’t be a big problem. Also, this is something you’ll want to hand off to your networking people.

If you do go the way of a site to site VPN, then you’ll want to think about compatibilities between your on-premises VPN gateway and the Azure Virtual Gateway. At one time, the Azure team had a list of what they called “supported gateways”, which implied that if your gateway wasn’t on the list, then it wasn’t supported. The wording has been changed a bit over time, and now there is a list of known “compatible” gateway devices. This list includes the gateways that Microsoft has tested and which are known to work.

You can find out more about Azure Virtual Gateways and VPN gateways that are currently known to work here.

Before wrapping up this discussion on VPN gateways, we did want to address a question that you might be thinking about. That question is “how do I test my site to site VPN connections? I don’t want to call in my network guys just to do some basic testing – but I don’t have the megahardware it looks as if I need to use. Any help here?”

Yes! This is a common question and the solution is to use the Windows Server Routing and Remote Access Service. You can use RRAS in Windows Server 2012 and above to connect to the Azure Virtual Gateway. For more information on how to do this, check out this link.


In this article, we went over Azure ExpressRoute and Azure Virtual Gateways. Azure ExpressRoute is a dedicated WAN link that you can use instead of site to site VPNs to connect your on-premises network to an Azure Virtual Network. Given that this is a dedicated link, you get performance, reliability, and security benefits from a dedicated circuit. Azure Virtual Gateways allow you to connect your on-premises site to an Azure Virtual Network using either or both sites to site VPNs or ExpressRoute. These gateways are routed connections between your site and Azure. When using site to site VPN connections, be aware of the list of VPN gateways that are known to work; this can save you a lot of grief. If you’re using ExpressRoute, you’ll work with your provider to determine the appropriate equipment and configuration of that equipment.

Next time, in Part 4, we’ll move on to discuss Azure Virtual Networks in more detail.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top