Azure Virtual WAN Migration

Azure Virtual WAN Migration

In this section , we will learn how to migrate from existing customer managed Hub and Spoke  topology to Microsoft-managed Virtual WAN hubs. 

 Problem Statement 

Dclessons is a global Training organization , with offices in both Asia and Europe. Dclessons are planning to move their existing applications from on-Premises DC to Azure and have already built out a foundation design based on customer-managed hub-and-spoke architecture across multiple regions , as shown in below figure.  

Below are the following points that can be leveraged from above topology. 

• A Hub and Spoke topology used in Multiple regions including ExpressRoute circuits for connectivity back to a common private WAN . 
• Some sites have VPN tunnels directly into Azure to reach applications hosted within the cloud. 

Dclessons Requirements

DClessons Architect Team has to deliver a global Network Model that can support the Dclessons Cloud Migration and must optimize cost , scale  and performance. 

• Optimize path for both HQ and branch office to cloud hosted Applications. 
• To remove the reliance on existing on-premises Data Centers for VPN termination while retaining the following connectivity paths. 
• Branch-to-VNet: VPN connected offices must be able to access applications migrated to the cloud in the local Azure region.
• Branch-to-Hub to Hub-to-VNet: VPN connected offices must be able to access applications migrated to the cloud in the remote Azure region.
• Branch-to-branch: Regional VPN connected offices must be able to communicate with each other and ExpressRoute connected HQ/DC sites.
• Branch-to-Hub to Hub-to-branch: Globally separated VPN connected offices must be able to communicate with each other and any ExpressRoute connected HQ/DC sites.
• Branch-to-Internet: Connected sites must be able to communicate with the Internet. This traffic must be filtered and logged.
• VNet-to-VNet: Spoke virtual networks in the same region must be able to communicate with each other.
• VNet-to-Hub to Hub-to-VNet: Spoke virtual networks in the different regions must be able to communicate with each other.
• Provide the ability for Dclessons roaming users (laptop and phone) to access company resources while not on the corporate network.

Azure Virtual WAN Architecture 

Below figure shows a High Level view of target topology , using Azure Virtual WAN to meet the requirements detailed in previous sections. 

• HQ in Europe remains ExpressRoute connected, Europe on-premises DC are fully migrated to Azure and now decommissioned.
• Asia DC and HQ remain connected to Private WAN. Azure Virtual WAN now used to augment the local carrier network and provide global connectivity.
• Azure Virtual WAN hubs deployed in both West Europe and South East Asia Azure regions to provide connectivity hub for ExpressRoute and VPN connected devices.
• Hubs also provide VPN termination for roaming users across multiple client types using OpenVPN connectivity to the global mesh network, allowing access to not only applications migrated to Azure, but also any resources remaining on-premises.
• Internet connectivity for resources within a virtual network provided by Azure Virtual WAN.

Internet connectivity for remote sites also provided by Azure Virtual WAN. Local internet breakout supported via partner integration for optimized access to SaaS services such as Microsoft 365.

Microsoft Virtual WAN Migration 

Below are some steps for migrating to Azure Virtual WAN. 

Step1: Single Region Customer-Managed Hub-and-Spoke

Below figure shows a single region topology for Dclessons prior to migration to Azure Virtual WAN. 

• Shared services (any common function required by multiple spokes). Example: Dclessons uses Windows Server domain controllers on Infrastructure-as-a-service (IaaS) virtual machines.
• IP/Routing firewall services are provided by a third-party network virtual appliance, enabling spoke-to-spoke layer-3 IP routing.
• Internet ingress/egress services including Azure Application Gateway for inbound HTTPS requests and third-party proxy services running on virtual machines for filtered outbound access to internet resources.
• ExpressRoute and VPN virtual network gateway for connectivity to on-premises networks.

Step 2: Deploy Virtual WAN Hubs

Deploy a Virtual WAN hub in each region. Set up the Virtual WAN hub with VPN and ExpressRoute functionality.