Explain By Example: VPN Gateway or ExpressRoute?
Find out more about VPN Gateway and ExpressRoute by becoming an undercover agent and eavesdropping on others.

Explain By Example: VPN Gateway or ExpressRoute?

Disclaimer: The following content is not officially endorsed by Microsoft.

Recently I watched Frank Abagnale's talk on YouTube and to be frank, I didn't know who he was (or is). If, like me, you have also been living under a rock, he is essentially the real life Leonardo DiCaprio off Catch me if you can.

Anyway, between climbing out of this rock I've been living under and studying for the Azure Architecture certification, I started thinking about the connection between undercover agents and Azure Networking or more specifically, the commonly asked question about whether one should pick VPN Gateway or ExpressRoute to connect to Azure.

As usual, I like to start with the basics before getting to the answer so...

What is VPN Gateway?

Azure VPN Gateway allows you to connect your on-premises network to Azure networks to send encrypted traffic over an insecure channel. But what does that really mean?

No alt text provided for this image

Let's say you have bunch of servers on-premises (which are just machines in some organization or some datacentre) and you want some of those machines to be able to connect and communicate with a bunch of Azure services (cloud services). This is an example of site-to-site connection. We have one site (on-premises) connecting to another site (Azure).

How does site-to-site connection work?

To enable site-to-site connection (S2S), we need to install a VPN device into one of the on-premises network. This VPN device allows you to connect to a VPN Gateway which you have to put into your Azure virtual network (VNET).

Technically, you have to carve out a section in your Azure virtual network (which is known as a subnet) called the Gateway Subnet. This subnet needs to have enough space for the VPN Gateway to use so you need use at least /27 (for 32 addresses) or /28 ( for 16 addresses) for this Gateway Subnet.

No alt text provided for this image

You also need to create a Local Network Gateway which is essentially a reflection of your VPN device that you have installed on-premises. The Local Network Gateway takes in the public IP address of your VPN device (think of it as this is where your VPN device is located on-premises) and the Address Space which is essentially the number of address spaces you have in that particular on-premises network the VPN device is install on.

Now, remember what I said before about VPN Gateway allowing you to send secure traffic over an insecure channel?

No alt text provided for this image

This is because the traffic gets encrypted before it is sent out like Frank Abagnale putting on a disguise before he took on an undercover job for the FBI or committing a crime. When traffic is encrypted, you don't really know what type of traffic it is nor the content of the traffic like when Frank was an undercover agent or committing fraud in disguise, you didn't really know it was Frank, you just know it was some pilot, some doctor, or some lawyer which meant the traffic can traverse over the internet (an insecure and public channel) freely just like how Frank could roam about freely under disguise. Once we get to the destination, we can decrypt the traffic to reveal its contents like removing a disguise to reveal Frank's true identity.

To set up for encryption and decryption, the VPN device must share encryption and decryption keys with VPN Gateway. This is called shared key or symmetric key encryption.

No alt text provided for this image

I won't go into details about encryption and decryption (maybe topic for another day) but essentially the VPN device and VPN gateway share the same encryption and decryption keys which means before traffic is sent out to the internet, it is first encrypted. When either party receives the traffic, they can use the decryption key to decrypt the traffic. All you need to know for now is that VPN Gateway supports IPSec/IKE protocols which is the industry standard for cryptography when it comes to VPNs.

Once your VPN device knows the shared secret keys to be used in information exchange as well as the public IP address of the VPN Gateway, you can create a connection between the two and viola! You have connected your on-premises to Azure.

VPN Gateway also supports what is called Point-to-Site (P2S) connections. Point-to-Site allows you to connect, say, your computer to your Azure virtual network. Again, the traffic goes over the public internet but because it is encrypted, it remains "anonymous", safe and secure.

Why would I use P2S connections?

No alt text provided for this image

Let's say you have successfully set up the S2S connection between your organization's on-premises networks to Azure. Now after all that hard work, your manager says, "Well done, you deserve a holiday" so you hop on the next flight out to Hawaii for a short vacation.


As soon as you touch down at Inouye International Airport, you get a call from your manager. "Help!" she starts to say, "One of our Dev environment is down and we need you to fix it immediately."

You roll your eyes and think, "I should really get a raise this year" but you don't say that. Instead, you tell her, "No worries, let me check into my hotel first so I can download the Azure VPN Client to securely remote into Azure through VPN Gateway and fix it."

P2S connection is really great for any remote workers that need to connect into your Azure VNETs securely over the public internet. An alternative to this (thanks to the suggestion by Manoj N.) is Azure Bastion which allows you to privately access your Azure VMs through the Azure portal so as long as you can securely access the Azure portal and identify yourself, you can access Bastion which you can think of as an agent that lives inside your Azure virtual networks that can then access your Azure virtual machines on your behalf.

After your vacation in Hawaii, you come back to find that everyone is talking about ExpressRoute and you start to wonder...

What is Azure ExpressRoute?

"Azure ExpressRoute" your manager starts to explain, "allows us to physically connect our on-premises networks into Azure."

No alt text provided for this image

Yeah, but why would we want to do that?

"Well, we don't want our traffic going over the internet anymore. And besides, we have been experiencing latency with more members joining the team and we keep getting internet outages, it's just a nightmare. Also, I overheard the CEO and CTO the other day talking about expanding the office to the other side of the country and..."

Sounds interesting enough, so you pull up Microsoft Docs to have a little read on the features and benefits of ExpressRoute.

No alt text provided for this image

You find that to create an ExpressRoute connection, you need to first create a circuit. The physical connectivity into Azure is done by an ExpressRoute partner so when you create a circuit, you are essentially asking your chosen ExpressRoute partner to set up a physical connection for you to connect to. They, on the other end connect this circuit into Azure.

Once you have created the circuit, you need to extract the Service Key and pass that onto your chosen ExpressRoute partner. Once your ExpressRoute partner has connected you, you will see the Provider Status in your circuit change from "Not provisioned" to "Provisioned".

No alt text provided for this image

Now that you have your ExpressRoute circuits activated, you can start connecting your Azure virtual networks to your on-premises networks over ExpressRoute. Similar to VPN Gateway, you need to create an ExpressRoute Gateway inside your virtual network before you can connect to the ExpressRoute circuit (like connecting to the VPN device). An ExpressRoute circuit can be connected to 10 different virtual networks and a virtual network can be connected to 4 different ExpressRoute circuits.

All traffic is now traversed over your own organization's networks and the Microsoft Azure networks which means even if the public internet crashes, it will not affect your traffic flow.

What happens when my ExpressRoute circuit goes down?

Your traffic flow to and from Azure will obviously get cut off so typically to ensure for high availability you would have two ExpressRoute circuits set up, one as a primary link and one as a secondary or backup link. For disaster recovery, you can set up one circuit in one region and another circuit in another region so even if the entire region (or city) goes down, your connection to Azure is not broken. And if you are really concerned, let's say, you are worried that you might end up having a dispute with your ExpressRoute partner, you can set up multiple circuits across multiple regions with multiple different partners. And if all that fails then we must have really hit strike on the Doomsday clock.

What was that part about eavesdropping on the CEO and CTO?

Another advantage of using ExpressRoute is leveraging the global Microsoft network. So your manager overheard that a new office is to be set up on the other side of the country and surely they would want to two offices to communicate privately rather than exchange their communication over the public internet but setting up a gigantic wire to connect the two office networks together will be too expensive. What can we do instead?

"With ExpressRoute Global Reach" you look up to find your manager say, "We can connect our two office networks together at a fraction of the cost by leveraging Microsoft's global network."

Gee, she's really keen on this ExpressRoute thing you think to yourself.

How does ExpressRoute Global Reach work?

No alt text provided for this image

"Quite simple" she starts, "ExpressRoute Global Reach connects ExpressRoute circuits together which means if we connected our main office to an ExpressRoute circuit and our new office to another ExpressRoute circuit then link those two ExpressRoute circuits together, we will be able to do all our office communication privately over the Microsoft network."

The CEO just happens to walk by and hears this and asks, "Does private mean the communication is encrypted?"

"No, the traffic that traverses over ExpressRoute is not encrypted but you can encrypt the traffic over ExpressRoute if you really want to with IPSec and Azure Virtual WAN".

So, should we pick Azure VPN Gateway or Azure ExpressRoute to connect to Azure?

And the answer is, that depends on your business requirements. VPN gateway is typically cheaper than ExpressRoute and whilst you get the anonymity and security of encryption with VPN gateway, you are still traversing over a publicly exposed and insecure channel and are dependent on internet providers for network consistency. With ExpressRoute, your traffic is not encrypted but it is private and you would experience lower latency than with VPN Gateway (think of ExpressRoute like plugging your device straight into the Ethernet port for faster internet speed vs. VPN Gateway relying on the wireless connection or WiFi) however this comes at a cost as you need to pay for hardware that is specifically dedicated to you.


That's it for now. Remember to leave me comments, feedback, criticism and/or ideas on what I should write next. Until my next post, stay safe and stay well!

P.S: If you want to support Explain by Example, you can buy me a coffee here

Illia Kozlov

Software Engineer | .NET | JS | React.js

1y

Thank you)

Like
Reply
Mohsin Hussain

Network & Security Architect | CCIE # 42576 (Sec & DC) | Azure | GCP

2y

Nice one with examples

Like
Reply

Thanks for this article. Any thoughts on Why does the Azure Virtual Network Express Route Gateway require public IP?

Like
Reply
Satish Verma

Cloud Operations Specialist at HCLTech.

2y

8min to read is worth

Like
Reply
Cliff Kanokanga

Solutions Engineer at USA CYBER Freelance IT Consultant | Azure Certified Cloud Engineer | Microsoft 365 Certified: Administrator Expert

3y

I really enjoyed reading this and you have explained Azure Gateway and Express route better than most Azure instructors. Thanks for this Michelle. 😎

Like
Reply

To view or add a comment, sign in

More articles by Michelle Xie

  • 5 years at Microsoft

    Disclaimer: Microsoft does not officially endorse the content of this article. All comments, views, and opinions are my…

    21 Comments
  • Explain By Example: Blockchain

    Disclaimer: The following content is not affiliated with Microsoft. Sometime back around July, I got challenged to…

    4 Comments
  • Explain By Example: Object-Oriented Programming (OOP)

    Disclaimer: The following content is not officially affiliate with Microsoft. I was taught the concept of…

    6 Comments
  • Explain by Example: Synapse Analytics

    Disclaimer: The following content is not officially affiliated with Microsoft. When I posted about my date with…

    12 Comments
  • Explain by Example: Identity and Access (IAM)

    Disclaimer: The following content is not officially affiliated or endorsed by Microsoft. A few weeks ago, I was in the…

    7 Comments
  • Two years at Microsoft

    A disclaimer (just in case): The following content are my own personal views and experiences, they do not reflect the…

    4 Comments
  • Explain by Example: Deep Learning (NN)

    Disclaimer: The following content is not officially associated or endorsed by Microsoft. I was at an airport recently -…

    1 Comment
  • Explain by Example: DDoS Attack

    Disclaimer: The following content is not officially endorsed by Microsoft. [Based on a true story] So I was just…

    3 Comments
  • Explain by Example: CosmosDB

    Disclaimer: The following content is not officially affiliated with Microsoft. Since I'm going to be giving a spiel (or…

    15 Comments
  • Explain by Example: Machine Learning

    Disclaimer: The following content is not officially endorsed by Microsoft. I've been wanting to learn about…

Insights from the community

Others also viewed

Explore topics