Azure Virtual WAN is a Microsoft-managed network service deployed to Azure. It provides a lot of functionality, including:

Branch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE).
Site-to-site VPN connectivity.
Remote user VPN connectivity (point-to-site).
Private connectivity (ExpressRoute).
Intra-cloud connectivity (transitive connectivity for virtual networks).
VPN and ExpressRoute inter-connectivity.
Routing, Azure Firewall, and encryption for private connectivity.

It is intended to simplify the configuration of VPN/ExpressRoute/SD-WAN connectivity and provide easy-to-deploy hub and spoke topologies with no complex routing tables or VNet peering config.

At the time of writing, it also supports Azure Firewall or FortiGate Next-gen Firewall deployment to the Virtual WAN hub. This can be configured to filter all traffic in/out of the hub (intra-VNet or Branch-Vnet traffic) and/or north/south internet traffic.

Azure Virtual WAN additionally supports multi-region deployments. Microsoft advise deploying a single Virtual WAN with ‘Virtual WAN Hubs’ in each region. Hub-to-hub traffic between regions is then also managed by Microsoft.

Benefits

The major benefit of Azure Virtual WAN is given the correct requirements it can significantly reduce the complexity of Azure networking. I have written a couple of blog posts in the past about deploying and connecting hub-and-spoke network topologies in Azure. These can be complex to say the least! In theory deploying a hub and spoke topology with Azure Virtual WAN should be a simple few clicks – Microsoft manages all the peering and routing for you. In some ways I like to this of Azure Virtual WAN as a ‘Hub and Spoke as a Service’.

Additionally, there is no need to deploy Virtual Network Gateways for ExpressRoute or VPN connectivity – this is all managed inside the Azure Virtual WAN portal, for example Point-to-site (User VPN):

Drawbacks

As is the case with any sort of Platform as a Service (PaaS) offering, removing the responsibility from the Azure administrator also removes control. If your customer has custom network requirements Virtual WAN can be complicated or even impossible to configure. An example of this is custom routing. If you have an Azure Firewall secured Virtual WAN hub with multiple spoke VNets and each VNet has different connectivity requirements (e.g., some VNet – VNet connectivity needs to bypass the firewall, while others needs to traverse it) it can be more complicated to configure than modifying route tables in a traditional hub and spoke. I also had a customer who needed to add custom routes to the Firewall subnet and I am pretty sure this isn’t supported at all.

There are also a large number of firewalls/NVAs which are not supported by Virtual WAN at all at the time of writing. For example, Palo Alto or Cisco. You can deploy these firewalls in their own dedicated VNet and connect to a Virtual WAN hub, but deploying directly to a Virtual WAN hub is not currently supported.

Finally, and in some ways I think this is the biggest issue with Virtual WAN, secured hub (Azure Firewall) to secured hub (Azure Firewall) traffic is not currently supported. This is a known limitation and Microsoft are working on a fix. I’ve been told Q1 2023 (so very soon) but at the time of writing, this is still not working.

Azure Virtual WAN

Benefits

Drawbacks

Further Reading

Leave a Reply Cancel reply