Hybrid Network Infrastructure in Microsoft Azure (Part 2)

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


By Tom 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. She also provided an introduction to the Datacenter Extension Reference Architecture Diagram that I put together with Jim Dial and several others at Microsoft. In Part 2, I’m taking the wheel and in this and subsequent installments, I’ll go into more details about the network functionality introduced in that article.

As a reminder, here’s a list of network capabilities that are available in Azure at the time this article was written (keeping in mind that this is “software-in-progress” so changes and new features are possible by the time you read this):

  • 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

I’ll go into a bit more detail about each of these and see if we can find something you might find interesting.

Site to Site VPNs

You can use industry standard site to site VPN technology to connect your network to an Azure Virtual Network. These site to site VPNs use IPsec tunnel mode, which is the same technology that you’ve been using for years to connect networks together over the Internet. When you configure a site to site VPN between your on-premises network and Azure, you establish a routed connection over the Internet.

Site to site VPNs to Azure are useful if you don’t have ultra-high bandwidth requirements. The default site to site VPN bandwidth is about 100 Mbps. There is an option for a high-performance site to site VPN gateway and if you choose that option, you can get up to 200 Mbps.

Remember, these site to site VPN connections are over the Internet, so Microsoft can’t realistically provide an SLA for anything other than their Azure gateway that your on-premises gateway connects to. Your uptime is going to depend on the reliability of your on-premises Internet connection and the overall reliability of the Internet, at least the reliability of all the networks that are between your datacenter and the Azure datacenter you’re connecting to.

Something to remember about site to site VPN connectivity is that you only pay for outbound bandwidth (which is data moving out from the Azure datacenter). You don’t have to pay for inbound bandwidth usage.

For example, if you want to copy a bunch of VMs to your Azure Virtual Network from your on-premises location over the site to site VPN tunnel, you won’t have to pay for the bandwidth you use, since that’s inbound bandwidth into the Azure datacenter.

There is also a nominal charge for the Azure gateway.

In the Datacenter Extension Reference Architecture Diagram it’s shown that Contoso could have used either a site to site VPN or ExpressRoute (which we’ll talk about later). Whether you use a site to site VPN or ExpressRoute really depends on how much bandwidth you need and if there’s a network provider in your area that supports ExpressRoute. If there’s no provider, then site to site VPN will be your only choice. If there’s a local provider, then bandwidth requirements will pretty much determine what type of hybrid network connection you’ll use.

Site to site VPNs are a great way to start any hybrid datacenter project because they are easy to set up and the costs won’t scare you. When you’re ready for a full blown deployment that requires gigabit speeds between on-premises and Azure, then you can start seriously thinking about setting up an ExpressRoute connection.

For more information about site to site VPN to Azure, check out this link.

Point to Site VPNs

I remember when Microsoft first introduced the term “point to site” VPN. I have to admit that I had no idea what a point to site VPN connection was, since I had never heard the term before. I figured that maybe I was out of the VPN business long enough where some brand new VPN technology was becoming predominant and I missed the memo on it.

That was not the case. A point to site VPN is a traditional remote access VPN client connection. I suppose the name point to site VPN sounded like a good idea since they wanted to make it clear that it was different from “site to site”. While this is self-evident to networking professionals, I suspect the intent for the name change from “remote access VPN client connection” to “point to site connection” was to make it clear that site to site VPNs connect entire network sites to each other, while point to site connects a “point” (a specific machine) to the Azure network.

Whatever the reason for slapping a new name on old technology, the fact is that you can create remote access VPN client connections, ah, I mean point to site connections, between a computer and an Azure Virtual Network. Like any other remote access VPN client connection, the client can be on-premises or anywhere on the Internet.

Point to site connections to Azure use the SSTP protocol. If you’re not familiar with SSTP, it’s the Secure Socket Tunneling Protocol, which uses HTTP as the protocol transport. SSTP is proxy friendly and uses the default SSL port, TCP 443. That means it’ll work just about anywhere, since we all know that the universal firewall open port is TCP 443.

The primary use case for point to site VPN connections is for a single developer or IT admin to be able to connect a management workstation to the Azure Virtual Network to reach virtual machines. The dev or admin fires up a VPN connection from the workstation to Azure and then connects to the virtual machines using their IP addresses or names.

From a network security perspective, this is a better option than using RDP over the Internet to connect to virtual machines. When you create a virtual machine on Azure, you are given the opportunity to allow inbound RDP connections from the Internet to that virtual machine.

This is convenient because all you need to do is run the RDP client connection that you download from the Azure portal and then connect to the virtual machine via that RDP client. Once you RDP into a machine on the Azure Virtual Network, you can then connect to any other virtual machine on the Azure Virtual Network from the virtual machine that you’re RDP’d into.

Point to site VPN connections are more secure because you have to authenticate twice. First, you need to authenticate to the Azure gateway to establish the VPN connection. After the VPN connection is established, you then can RDP (or remote PowerShell or SSH or whatever you want to use) into any of the virtual machines on the Azure Virtual Network. Of course, when you RDP into the virtual machines after you make the VPN connection, you’ll need to authenticate again.

Sure, needing to authenticate twice is more secure than needing to authenticate once. But the real security advantage is that you’re using two different authentication repositories (or at least accounts) for the two authentication events. You create the point to site connection using accounts that you use to connect to the Azure portal, and then you connect to the virtual machines using either local accounts on the virtual machines, or domain credentials (if you decided to extend your domain into Azure, or if you created a new Active Directory in Azure).

Note that there are scenarios where you federate credentials that can be used both for access to the Azure portal and to connect to the virtual machines, but I don’t want this to get too complicated at this point.

For more information about point to site connections to Azure, check out this link.


In this Part 2 of this series, we started a more detailed discussion about the network related technologies that you can use when you plan and design a hybrid IT environment. We began with a discussion of site to site VPNs and how you can use them to connect your on-premises network to an Azure Virtual Network. Then we went over point to site VPNs, which are actually remote access VPN client connections that use SSTP for their VPN protocol. In part 3 of this series, we’ll cover the other Azure networking technologies in the list. Keep in mind that Azure is a work in progress and what we talk about today might have changed over time. Always make sure to visit www.azure.com for the most up to date information.

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

Leave a Comment

Your email address will not be published.

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

Scroll to Top