Comparing Networking Options in Azure

What are your options for connecting to an Azure VM? Sure, a Remote Desktop Protocol (RDP) connection will get you started but you'll soon need a full secure VPN connection. Azure can provide three different options for doing this: Point-to-Site (P2S), Site-to-Site (S2S), and ExpressRoute, but what are their relative advantages, and which one is right for the way you need to use Azure?

If you’ve been playing with Azure for a while, you know it’s easy to connect to the virtual machines (VMs) that you create. Just click on the connect button, download the Remote Desktop Protocol (RDP) file, and away you go. But maybe now you’re ready to get serious about testing some infrastructure in Azure, or maybe your business is getting ready to use it and your boss just tasked you with figuring out the connectivity. In any case, you’re going to need more ports and full connectivity-not just RDP. And it needs to be secure.

Azure has three options for VPN connections to your cloud resources: Point-to-Site (P2S), Site-to-Site (S2S), and ExpressRoute. Choosing the right option will come down to two factors: how many devices you need to connect to your Azure infrastructure and how fast and reliable those connections need to be. Keep in mind that you aren’t limited to a single option and your solution may not even be the same for all of your users all of the time. 

The thing these three VPN options have in common is that they allow you to connect to an Azure virtual network. We’ll start there so we have something to connect to. Azure is itself, of course, a massive network of computers, but you can configure a virtual network for yourself within it. This article isn’t intended to be a detailed tutorial, but there are plenty of them out there like this one that shows you how to create a virtual network using four different techniques, or this video on YouTube. The point here is that before you can get started with any of these VPNs, you need to have the same things running in Azure that you would need to connect to any other kind of VPN destination. For example, you’re going to need DNS Services on the Azure side, a functioning gateway, and clients to connect to in Azure that are running in an IP address space that does not overlap with yours. These can all be set up in the Azure administration portals. 


With a Point-to-Site VPN, you can connect a single computer (the point) to your Azure network (the site), and your computer will be authenticated to the VPN using certificates. If you are using Azure VPNs on your own and only connecting a single computer, you can create a set of self-signed certificates with the MakeCert tool that comes with Visual Studio. I say “a set of certificates” because you’ll need to create a root certificate and a client certificate. The root certificate will be used to sign the client certificates, and it’s public key will be uploaded to Azure so it can be used to cryptographically validate your computer’s client certificate.

Again, in the case of simply connecting a single computer, you can use MakeCert to create the root certificate by starting the Visual Studio Command Prompt, changing the directory to the folder where you want the public key .cer file to be created, and issuing the following command: makecert -sky exchange -r -n “CN=RootCertificate” -pe -a sha1 -len 2048 -ss My “RootCertificate.cer”.

You should now have a self-signed root certificate in your My certificate store and a public key file in your current folder. You can now use MakeCert to create a client certificate that is signed by the certificate you just created by issuing the following command: <code>makecert.exe -n “CN=ClientCertificate” -pe -sky exchange -m 96 -ss My -in “RootCertificate” -is my -a sha1</code>. Keep in mind the names RootCertificate and ClientCertificate are examples only. Make sure you give them names that are meaningful to you.

Now that your client certificate is created, you can upload the root certificate’s .cer file to Azure by either clicking on “Upload a root certificate” in the certificates section of the Azure classic portal or by issuing the correct <code>New-AzureRmVpnClientRootCertificate PowerShell command.

It’s worth noting at this point that even if you are responsible for a lot of users with their own machines and you eventually choose the S2S option for most of your VPN needs, there are times when you might still want to have the P2S option available to them. For instance, if they have a laptop and want to connect to the Azure VMs from a remote site, they might use the P2S VPN client. Managing a bunch of self-signed certificates for many clients can become a real pain, and this is when it might be worth looking into Active Directory Certificate Services (AD CS). With AD CS, you can upload a single root certificate to Azure to cover all of your machines and then let Active Directory and Group Policy worry about the details of provisioning the client certificates to each machine, renewing them when they expire, and providing a single point of configuration for managing certificate security policies. Setting up a domain certificate authority can seem like a daunting task, but Defense in Depth and encryption are becoming more and more important these days. If you have a lot of machines you are responsible for, a functioning certificates infrastructure can pay off big.

After the certificates are uploaded, you can create and download the VPN client configuration tool either by clicking on the VPN package on the dashboard of the classic portal or by issuing the <code>Get-AzureRmVpnClientPackage</code> PowerShell cmdlet from the client computer (if you’re using the new deployment model). You’ll then need to navigate in a browser to the URL that it returns to download the package. Note that this is not installing additional software; the P2S VPN uses the VPN client that is built into Windows and the package merely configures it for connecting to Azure. The configuration package will take you through a series of prompts after you launch it to complete the configuration. When that’s done, you should be connected and have full VPN connectivity to your machines and services over a secure tunnel.

If you want a detailed walk-through of how to set this up, Azure has an excellent article on P2S that you can follow along step by step.


A Site-to-Site VPN tunnel is great for when you need a persistent connection from many on-prem devices and computers to your Azure network. This is an ideal option for creating hybrid cloud solutions where you need to be able to connect to your Azure resources seamlessly. As you might expect with a more powerful solution, there are some additional hurdles to jump through in order to get this working. For one, you’re going to need some specialized networking equipment and you’re also going to need a static public IP address. You can’t use network address translation (NAT) for this connection.

On the Azure side, you’ll need to create your virtual network just like you did with P2S, but this time you are also going to need to define your on-prem network. This is where using this solution is going to take a little more thought and planning. Just like any Site-to-Site VPN, both sides need to know what IP address range should be sent over the tunnel. This means that in Azure you are going to need to configure each on-prem network that you want Azure to be connected to and the subnets that it should be able to communicate with.

If you’re a networking professional, you may already be aware of this, but another difference between S2S and P2S is that S2S is authenticated using a pre-shared key (PSK) instead of certificates because it uses Internet Protocol Security (IPsec) rather than Secure Socket Tunneling Protocol (SSTP). You can have the Azure tools generate a PSK for you, or you can manually configure one that you have generated yourself. This means that the networking equipment will handle maintaining the encryption of the tunnel itself, and the computers and devices communicating over the tunnel don’t each need an individual certificate to identify themselves and encrypt their own connections.

Once again, if you’d like more detail, including a step-by-step walk-through of how to get this up and running, Azure has a helpful article on S2S on their documentation site.

Microsoft says that for both of the options outlined so far-P2S and S2S-they are seeing typical connection bandwidths of less than 100Mbps. They say this is good for scenarios like development, testing, labs, and small-scale production use of cloud services and VMs. If your business is really going all in on the cloud, you are probably already thinking that you need something more-you need a VPN that is going to be blazing fast with bulletproof reliability. 


ExpressRoute is a VPN type that Microsoft offers in partnership with several connectivity providers to allow businesses to connect from their co-location facilities-or their internal networking equipment-directly to Azure domain controllers (DCs) without traversing the public internet. The speeds you can connect at start at 50Mbps and go all the way up to 10Gbps. If you’re using Azure for things like off-site backup of large files, disaster recovery, or business-critical apps that get a lot of traffic, you might consider this option. ExpressRoute circuits can also carry up to three independent peerings to carry three different kinds of traffic: public, private, and Microsoft. 

Private peering is for extending your infrastructure directly into the cloud transparently. This makes Azure VMs effectively just like machines sitting in your datacenter. Public peering will get you a private, fast connection to Azure services offered on public IPs like Azure websites, SQL databases, and storage. Microsoft peering is for things like Office 365 and any other traffic that doesn’t fit into the other two categories.

When you connect via ExpressRoute, you are basically extending your network into Microsoft’s cloud networking fabric. If you are in a co-location facility with cloud exchange, you can order virtual cross connections through your provider’s Ethernet exchange. They should be able to offer you either Layer 2 or Managed Layer 3 connections directly between your infrastructure and the Microsoft cloud. You can also get Point-to-Point Ethernet connections at Layer 2 or 3 and Any-to-Any (Internet Protocol Virtual Private Network [IPVPN]) as well. 

All of these connections will be offered redundantly to ensure the validity of the uptime of the service-level agreement (SLA) that Microsoft offers on these connections. If you think this kind of connection is for you, then you should definitely be contacting your in-house networking staff and talking to your co-location provider or your telco. Let the professionals set this one up. If your networking team needs an overview, you can send them to this ExpressRoute tutorial and video.


As we’ve just seen, regardless of the size of your organization-whether you’re a one-man hobby shop or a Fortune 500-Azure has a secure connectivity option that will work for you. If you only have single computers to connect to your VMs and you don’t want to fuss with a bunch of networking stuff, P2S is probably your best option. If you have more machines that need to connect, devices that can’t use a client, or infrastructure that needs to connect seamlessly-and if networking doesn’t intimidate you or you have a networking team-then give S2S a shot. Finally, if you’re a large company that is diving into the cloud in a big way and you need world-class speed and reliability, you should take a serious look at investing in an ExpressRoute connection.