What is Azure Virtual WAN?

As you might have seen from other posts, I’m currently writing more articles around Azure Virtual WAN and today I want to have an in depth look at what Azure vWAN is.

To start off, I’d like to mention that I’m a huge fan of virtual WAN and I do a lot of projects with customers and virtual WAN. But to be honest, there is no straightforward yes or no answer when it comes to choosing Azure vWAN over other tech, such as Azure Network Landing Zone.

Within today’s post, I will share some of my knowledge and opinions around Virtual WAN and discuss the most often mentioned questions by customers:

• What is Azure Virtual WAN?
• What is the difference between Virtual WAN and SDWAN?
• When should I swap from Classic Hub and Spoke to Virtual WAN?
• What are the benefits and downsides of Virtual WAN?

I work with Virtual WAN customers on a daily bases, so I will try to keep the explanations as short as possible and will try to give you some more real-life examples and opinions.

What is Azure Virtual WAN?

Many people think Virtual WAN is like another connectivity method from Azure like Azure ExpressRoute (direct) or VPN but you can think of virtual WAN like an umbrella which includes lots of services including connections to Azure ExpressRoute and VPN. Azure Virtual WAN is a managed networking service which brings together networking, connectivity, security, monitoring and routing features. Virtual WAN has and will also improve the single point of management for all these features. With Virtual WAN you have a single management interface for these services.

Virtual WAN includes connectivity solutions like ExpressRoute, VPN for Site to Site and Point to Site connection, as well as the integration of SD-WAN and VPN CPE Partners. I will give you some more background Partner CPE solutions later in the post. Virtual WAN can also make use of Azure Firewall and with that you can encrypt private connections or establish a centralized internet breakout from the Azure backbone and leverage the Microsoft Edge and Peering environment to other providers.

Many people think of virtual WAN as “I need to take all” solutions but virtual WAN scales on demand. That means you can start small and only use virtual WAN as a single VPN hub and later on add the other features on demand. You can also scale down if you no longer need features or different hubs.

When deploying virtual WAN it always consists of the following resources.

-> The virtual WAN Management resource

Currently, the Virtual WAN Management resource is bound to a region and it is not replicated to another. That resource only holds the configuration itself and represents the virtual WAN infrastructure. Active components will get separate resources deployed.

If the region where you have deployed the virtual WAN resource becomes unavailable for some reason, the virtual WAN hub goes into read-only mode. Which means you still have a working backbone and solutions but you cannot do changes. So my suggestion, always deploy your hub resource in larger regions like North / West Europe etc.

–> The Virtual WAN Hub

Beneath the Virtual WAN Management resource, you deploy the virtual WAN hubs. These hubs are region-bound and are deployed to the Azure Region which you choose for the deployment. It will also leverage the local resources like IPs or VM capacity. Normally you can deploy Azure virtual WAN in every Azure Region globally but there are two small limitation with sovereign regions like Azure China or satellite regions like Azure Germany North (Berlin) or Azure France South (Marseille).

• Azure Sovereign Regions
  • As you may know, sovereign regions are completely disconnected from the Microsoft Global Network and Active Directory. For virtual WAN they are handled like any other VPN or ExpressRoute site like datacenters or branches. To connect to a global virtual WAN hub, you would need to configure a virtual WAN in a sovereign region and Azure global and connect them like every other remote site.
• Azure Satellite Regions
  • A Satellite Region is part of the Microsoft Global Network and Active Directory but by default not accessible for customer deployment. They are only build for in-country redundancy if customer is requiring any. To deploy into these regions, you need to whitelist your subscription via an Azure Support Ticket. After your subscription is whitelisted, you can deploy to that region.

—> Virtual WAN Gateways, Firewalls and Appliances 

Within the hub you than deploy the resources needed, like your gateways and other resources.

Virtual WAN architecture is always a hub and spoke architecture. That means virtual WAN will be the interconnect and security hub with built-in branch and user connectivity which includes automated performance and scalability. The spokes are connected via virtual networks or branches. Those virtual network spokes can be regular application spokes or special shared services spoke. Especially the shared service spokes are a necessary compromise in virtual WAN because there is no option to deploy for example Domain Controller or Management Servers in a Virtual WAN hub. These services must be deployed into a spoke. Here you can find more details on the shared services spoke architecture. Scenario: Route to Shared Services VNets – Azure Virtual WAN | Microsoft Docs

Talking about architecture, a very important point of the Virtual WAN architecture is the global transit capability. That ability allows customers to transit traffic through the Microsoft Backbone globally without the use of a 3rd Party Backbone provider like AT&T, British Telecom, TaTa or others. In my opinion, that’s an awesome opportunity to reduce costs and improve performance because you can always choose the locally best provider and do not need take care of peerings between providers or have high-priced contracts with a central connectivity provider.

Such an architecture could look like below.

If you want to learn more about the global transit network architecture and the Microsoft Global Network, please follow the links below.

• Architecture: Global transit network architecture – Azure Virtual WAN | Microsoft Docs
• Microsoft global network – Azure | Microsoft Docs

What is the difference between Virtual WAN and SDWAN?

When you look at Virtual WAN itself, it is a Software-Defined WAN (SD-WAN). Virtual WAN is designed to enable seamless, scalable and unbreakable backbone network to interconnect with other on-premises SD-WAN devices, services and technology.

There are many services in the field provided by Solution Partners and Azure Networking Managed Services Partners in the Microsoft Azure Virtual WAN ecosystem.

So to shortly answer the question, virtual WAN is based on SDWAN but cannot be a full last-mile solution for SDWAN. It builds more like a SDWAN aggregation point and backbone extension. So it would be a great addition to a Software Defined WAN ecosystem.

To learn more about Azure virtual WAN and Software-Defined WAN, you can read a great article by Dr. Reshmi Yandapalli, Principal PM at Microsoft Azure Networking.

Virtual WAN managed CPE Partner

First, let’s learn what a CPE is. CPE means, customer premises equipment. Basically we are talking about a Firewall, Router or SDWAN Edge device which connects the customer on-premises to the Internet or a Private Network.

Azure Virtual WAN is working with a list of those CPE Partners. The list below shows you a reference of the currently available partners.

Source: Microsoft Docs

With supported devices from those partners, you have the option to configure zero-touch CPE deployments. That means you can preconfigure an environment where a new CPE (out of the box), can connect to. Those devices than directly connect to a management service from their vendor and get the connectivity details to connect to a customer virtual WAN.

After they are connected to virtual WAN, virtual WAN will start to manage the connections to other Branches, virtual WAN or other connected services.

Such a workflow could look like:

1. An employee on-premises unboxes the CPE and connects it to the Internet
2. Employee gives the serial number and access code from the box to a service engineer
3. The service engineer logs into the CPE Partner service portal and authorizes the CPE and pushes the configuration on the device
4. CPE connects to virtual WAN and is adding itself to the branches
5. CPE receives configuration and routes to other branches, Azure, and other connected infrastructure
6. Virtual WAN receives network changes and distributes them automatically to all connected CPEs

You can also use unmanaged CPEs as shown in one of my previous articles.

In that case, you would need to manage every single device and routing. You could make it a bit simpler by using BGP for routing optimization but you would still need to add the VPN Sites and on-premises device configuration manually. Depending on your infrastructure, that can be very complicated and time-consuming.

I personally use currently the unmanaged options because I only have three sites in my test environment but it is already annoying to manage.

Virtual WAN Upgrades

Virtual WAN as a managed service has two SKUs and different additional upgrade and integration with other products.

The lowest level of SKU which is available with virtual WAN is basic. In Basic mode, you can only connect VPN Site to Site connection and connect to virtual Networks. It somewhat replaces a traditional Azure VPN GW and prepares your environment to become a global backbone solution.

With a simple “click” like shown in this documentation, you can upgrade a basic virtual WAN hub to a standard one.

With a standard virtual WAN hub you get the opportunity to add Azure ExpressRoute and Point to Site VPN Gateways. In addition, you can also connect with other virtual WAN Hubs around the cloud and enable global inter-Hub routing as well as VNet-to-VNet traffic transit without using a Network Virtual Appliance or Azure Firewall as a router.

With that extension, virtual WAN is already a great solution to build a massive global backbone, based on the Microsoft Global Backbone.

Based on the virtual WAN you can now add additional solutions.

Azure Secure Hub with Azure Firewall

By introducing Azure Firewall into Azure virtual WAN, a regular unsecured virtual WAN hub will become a secured hub.

When upgrading to a secured hub, security and routing policies will be introduced, handled and configured by Azure Firewall and the Azure Firewall Manager. A secure hub makes it easier for a customer to create a hub and spoke network architecture with native and integrated security services. That makes it easier to govern and protect network traffic transiting through the customer network in Azure.

Currently, you can use a secured hub to filter traffic between virtual Networks, virtual Networks and branch offices and on-premises locations. It is also possible to secure traffic to the internet from branches and virtual Networks. What currently is not possible, and will be fixed during the next release cycle (January to July 2021) of Microsoft, is securing the traffic from one secured hub to another secured hub.

You can use a secured virtual hub to filter traffic between virtual networks (V2V), virtual networks and branch offices (B2V) and traffic to the Internet (B2I/V2I). A secured virtual hub provides automated routing. There’s no need to configure your own UDRs (user-defined routes) to route traffic through your firewall.

You can choose the required security providers to protect and govern your network traffic, including Azure Firewall, third-party security as a service (SECaaS) providers, or both. Currently, a secured hub doesn’t support Branch-to-Branch (B2B) filtering and filtering across multiple hubs.

To learn more about Azure Secured Hub, please visit the Microsoft documentation.

Network Virtual Appliance Partners

In 2020 Microsoft introduced the first Network Appliance Partnership and the first appliances natively integrated into virtual WAN. The first partner that time was Barracuda Network with their cloud gen WAN appliance. Currently Cisco Viptela and Barracuda are the only Partner available, but by the end of 2021, many other tier one SDWAN and Security vendors will join the virtual WAN NVA portfolio.

These Appliances will be deployed in virtual WAN in an own subnet behind an Azure Loadbalancer. These appliances will run as a Virtual Machine Scale Set (VMSS), which means their are highly available and you can easily add additional appliances to the NVA Cluster to add capacity. The NVA then talk External Border Gateway Protocol (EBGP) to the Azure virtual WAN Route Service who orchestrates all routes from all gateways, peerings and integrated services like Azure Firewall.

With the following image, I want to try to illustrate the routing flow. It is not perfectly accurate, but it explains the concept.

Microsoft is heavily working to improve the NVA experience, routing and partnership of virtual WAN. In the end, NVA integration should become easy and scalable without the struggles in regards to redundancy and scaling as you have with a classic VNet deployment.

When should I swap from Classic Hub and Spoke to Virtual WAN?

First things first, even if you hear it from your consultants or even from a Microsoft Cloud Solutions Architect, Azure Virtual WAN is not a solution for every networking architecture. It is a managed network service, which should make seventy per cent of network scenarios easier for customers. There is still thirty per cent of scenarios where Virtual WAN cannot solve the issue and may even make things more complex.

The following table may help during daily business decisions in regards to virtual WAN.

There are many more things to consider on what solution to choose. As you may know, every project and infrastructure is different. Maybe the benefits of virtual WAN can sometimes become disadvantages, but one thing I always plan on is to keep an architecture open in order to switch back and forth.

What are the benefits and downsides of Virtual WAN?

When looking at virtual WAN there are some great benefits but also some downsides you maybe need to know.

Benefits: 

• High available Gateway and Backbone infrastructure
• Easy up and downscaling of the hub environment without any downtime
• Rich feature set and automation
• One of Microsoft networking focus services
• Large Partner ecosystem
• Managed Service for network connectivity, routing and security

Downsides: 

• Complex services to understand in the first place
• Flexibility and solutions limited to the available feature set compared to a classic hub and spoke

There are always reasons to use a hub and spoke instead of virtual WAN. Please do me one favour, always check the virtual WAN feature set and support-ability against your scenario. Sometimes Microsoft and Partners want to sell you virtual WAN as the incredible unicorn to solve all network requirements. From my personal experience, virtual WAN is an awesome product and I really love to work on projects and customers with virtual WAN but virtual WAN cannot cover all scenarios yet.

When should I use Azure Virtual WAN?

Within the last part of my post, I would like to give you some scenarios I tend to cover with virtual WAN when I work with my customers.

Building a global unified Network Backbone

As described above, a perfect use case for virtual WAN is to be used as a global unified full meshed network backbone. In that scenario, a customer builds entry points and virtual WAN hubs near every office location or mobile workers around the globe.

With such a solution you get a virtual WAN to virtual WAN Hub backbone connection capacity from about 40 GB/s and a possible entry capacity from 20 GB/s per Gateway type. That means you have 20 GB/s  capacity with ExpressRoute per Regions, 20 GB/s or 10.000 Users (limit will be raised soon) per Point to Site VPN Gateway, and 20 GB/s (2 GB/s per tunnel) for Site to Site VPN Gateway. With Network Virtual Appliances like Barracuda Next Gen WAN in virtual WAN even more capacity is possible. Plus price efficient internet or private network connections with a local network provider, that gives the customer a very price-efficient and extremely scalable global backbone solution outside any other solution on the market.

Build your own Cloud Exchange platform

One thing I really like and described in one of my older posts is the option to use virtual WAN as a cloud exchange platform with routing automation. How you can build such an exchange with the use of ExpressRoute, virtual WAN and Partners like Megaport or DE-CIX is described here. How to use Microsoft Global Network with Oracle, Google or AWS (altaro.com)

But there is a hidden secrete in virtual WAN. Did you know that you can use virtual WAN VPN gateways to connect to other clouds and routes between them? Normally that would not be possible because another cloud provider and a regular Azure VPN Gateway is just a IPSec VPN responder and you would need a 3rd party device to establish the tunnel. Virtual WAN instead can be configured as IPSec VPN initiator.

Source: Azure Virtual WAN default IPsec policies | Microsoft Docs

With that option and configurations, you can easily establish IPSec VPN tunnels between all cloud platform like AWS and GCP. On another note, using public IP connections and the Internet to connect to the other, is not such a bad idea. All three big providers maintain a good peering relationship between each other. Like we say in the peering community, “Peering we trust”, even if we are in a (un)friendly competition.

Build a highly secured private internet break out via Azure Backbone

When configuring Azure virtual WAN and for example using secured Hub, you can announce a default route to your clients and branch offices. With that, you can use the Microsoft Global Backbone to provide you with a highly redundant, secured and awesomely peered Internet Breakout.

Microsoft is heavily investing in its peering relationship to network providers and in its backbone security. You can read more about it here.

For customers who want to use ExpressRoute, it has another benefit. With the use of Azure Virtual WAN and secured Hub, you are allowed to transit  Office 365 traffic via ExpressRoute private Peering to the Azure Firewall in virtual WAN. It is the only recommended solution using ExpressRoute for Microsoft 365. As you might know, Microsoft is not recommending using ExpressRoute in any other case for Microsoft 365 traffic.

You can also use Virtual WAN to double-encrypt traffic for other PaaS and SaaS service. The first encryption comes from the service itself because it is encrypted with SSL, and the second encryption can be established using IPSec over the Internet or ExpressRoute using the Gateway private IP.

To learn more about Internet Security with virtual WAN, please visit the virtual WAN security Baseline.

Integrate unmanaged Networks after acquisitions

A good example of virtual WAN flexibility is a scenario I was faced with several times in the last two years. A customer made an acquisition of another company that was using a completely different WAN strategy. In most cases, I had customers already using SDWAN appliances and they acquired a company with a very tradition MPLS network.

A normal solution to interconnect those two networks would be an additional MPLS connection within a customer datacenter or main office location or an additional internet connect and SDWAN appliance in the acquisition datacenter of the office location. Those locations would then be used as a hub site. Depending on the size of the company, you might need to have such a hub on every major continent.

To be honest, that is a good, very common and proved strategy but with one downside. A customer mostly only needs such an interconnect hub only for a few months to max 2 years until the network of the acquisition is fully integrated into the corporate network. Those hub solutions come mostly with high costs and with long term commitments like MPLS network connections.

With virtual WAN you can just spin up a virtual WAN hub in a region you prefer and which is near to the corporate and acquisition offices and you can connect an Azure ExpressRoute or VPN connection to the hub. As soon as you integrated the acquisition network and you no longer need the virtual WAN hub for interconnect, you can just tear or scale it down.

There is currently only one small show-stopper. If you have overlapping IP Ranges between both networks and you do not have the option to NAT on the branch location, virtual WAN in its native setup cannot be used. But that is a small gap which Microsoft will solve sooner or later because it is a highly asked improvement from many customers.

Currently, you can build a workaround by using Barracuda NVA in the hub or using a Network Virtual Appliance from any Partner and terminate the VPN tunnels onto that appliance. Then you can use the Route feature in virtual WAN and the NAT service on the appliance to establish connections and routing via the Microsoft Global Network and virtual WAN. I will not describe the architecture for that design in the current blog, that would be a topic on its own. If you like to read about that topic, please leave me a comment.

In the meantime, I would like you to check out the listed Microsoft docs below.

• About virtual hub routing – Azure Virtual WAN | Microsoft Docs
• Azure Virtual WAN: About Network Virtual Appliance in the hub | Microsoft Docs
• Scenario: Route traffic through a Network Virtual Appliance (NVA) – Azure Virtual WAN | Microsoft Docs

Closing Thoughts

Ok, that was a very long post. One of the longest I ever wrote for Altaro. Thanks for reading through it, I hope I was able to give you some more clearance and insides about virtual WAN, its possibilities and applicability. If you have any questions, feel free to leave a comment, email me, or send me a tweet.