Using Azure Virtual WAN

Virtual WAN Architecture

Microsoft has a new Enterprise Scale Virtual WAN Architecture. It’s not explicitly stated that it will replace Hub and Spoke but with the simplified configuration and the fact it is making your WAN PaaS in Azure, I think it would be only a matter of time.

So, what is it? The diagram below from Microsoft shows the architecture:

Rationale

We recently implemented this for a client and at that time the reasoning for using Virtual WAN was as follows:

1.      Greenfield Environment. VWAN is part of Microsoft’s new Enterprise Scale Architecture and if we are starting from scratch using a future-focused architecture means things will be deprecated less quickly.

2.      Multiple Geographies required. Global Connectivity using the Azure Backbone is part of VWAN and needed by the client.

3.      Native Azure Firewall with Azure Firewall Manager.

4.      Full-Mesh Architecture. There will be multiple spokes. These spokes can be controlled using Azure Firewall rather than manual configuration connecting spokes to each other when required in a Hub and Spoke scenario.

5.      Multiple WAN Providers Planned. SD-WAN is needed and Virtual WAN integrates with a growing list of providers.

6.      Simplified Configuration for VPN. The VPN setup has been simplifies and its great to see the VPNs and manage them in one pane of glass.

7.      There is Native Express Route encryption in Virtual WAN. We are not sure if this will be used yet, but the option is there.

For a full drill-down into all the benefits and features see this link: https://docs.microsoft.com/en-gb/azure/virtual-wan/ suffice to say the above list of benefits was enough to convince the client to go for this architecture.

Challenges

There were a few minor challenges.

·        We found that after deploying a VHub we couldn’t add a vNet to it. It told us there was a routing issue. If you reset the hub or add a VPN Gateway then the issue disappears. It’s minor but had me scratching my head for a few minutes.

·        Routing wasn’t working properly from a spoke vNet through the Azure Firewall. We had some workarounds, but Microsoft were doing some remediation work and this has been resolved now.

·        Older hash algorithms will not work in the new VHub VPNs. One of the VPNs we were required to setup for a 3rd party used SHA1 which is long deprecated. We have advised them to upgrade their NSX Edge to 6.4 in order to remediate but we are still waiting on this. However, the new VPN setup does allow IKEv1 (surprisingly) – so not all legacy protocols have been removed. In order to use IKEv1 there is a process that needs to be followed. You have to create the connection with no association to a VHub and then connect it manually after.

·        There is one pane of Glass as such but many layers. If you go to VPNs under the Hub you get different options than if you access via higher in the VWAN tree. It’s simply a matter of getting used to the UI.

Final Thoughts

At the outset, my view was that if there are multiple geographies then a move from Hub and Spoke to Virtual WAN is a no-brainer. But after seeing it in action I think I would be tempted to use this architecture in an environment that has a single geography i.e. UK South and UK West. The reason for this is threefold: the simplified configuration of the WAN Services and, secondly Azure Firewall is built in, native and managed centrally with Azure Firewall manager. Finally, the full-mesh architecture means there is less manual configuration of vNet peering. These three benefits mean that if you have a greenfield environment to be stamped out then you should seriously consider VWAN if it aligns with the customer requirements.