Azure Virtual WAN is the newest network service that brings many network functions (networking, security and routing) together to provide a single operational interface. The network services functionality includes Site to Site VPN, Point to Site VPN, Express Route connectivity, routing, Firewall & Encryption and branch office connectivity. The connectivity and management of all networking functionality is managed via the Azure cloud portal, as a single window.
To keep it simple, Virtual WAN is Hub and Spoke architecture with connectivity and functionality to connect all your sites across the globe by leveraging a default transitive routing behaviour. Azure Virtual WAN is a Software-Defined WAN (SD-WAN), The Hub is a virtual managed network hosted in Azure cloud whilst connected spokes can be different types of endpoints (branch office, multi-cloud and express route). This service provides a full mesh network connectivity.
The below picture provides a detailed architecture and terminology used in Azure Virtual WAN:
Figure 1- Azure Virtual WAN
Virtual WAN: represents a virtual container of Azure networks and collection of multiple resources. It contains links to all your virtual hubs that you would like to have within the virtual WAN.
Virtual WAN has two offerings:
|Virtual WAN Types||Configurations||Features|
|Basic||Site to Site VPN only||It's not full mesh connectivity.|
|Standard||ExpressRoute, Site to
Site VPN, Point to Site (User VPN)
connectivity. Inter Hub and Vnet to Vnet via virtual HUB.
Virtual HUB: is a managed virtual network in Azure, these resources are not visible in your subscription. The spoke network connectivity (Branch office, Express Route, etc) are connected to Virtual HUB. The hub will have virtual network resource and associated address spaces (minimum of /24), a hub gateway is used to connect VPN and SD-WAN/VPN partner devices. Azure Virtual networks can be connected to a hub with a hub virtual network connection [resource?] for integration. Virtual Hub can have an Azure firewall or one of multiple Azure approved partners firewall devices for security.
The Approved Partner list is growing, some of the partners currently on list include:
Hub to Hub Connection: Hubs within virtual WAN can be connected to each other enabling full-mesh connectivity across branches or VNETs using the Microsoft backbone. However, this is only available in the Standard offering.
Hub route table: This provides an option for restricting access to VNETs via a route table.
Site: This is used for connecting VPN devices to Virtual HUB.
Traffic Flow in Virtual WAN
Let’s assume an organisation has offices in the US and Australia with cloud footprints on Azure in both regions, a virtual WAN for this organisation is represented by the below diagram. The traffic from the Australian office to US Azure region will flow across Site to Site VPN and the Microsoft backbone with interconnectivity between virtual hubs across regions.
Figure 2- Azure vWAN Traffic
Let’s create the lab as per below diagram and perform test connectivity.
Figure 3- LAB Setup
Steps to create virtual WAN:
In this section, we will create an Azure Virtual WAN.
1. Log into the Azure portal and search for the Virtual WAN.
2. Select Virtual WAN from the results. On the Virtual WAN page, click Create.
3. On the Create WAN page, fill in the required details :
Figure 4: Creation of Azure vWAN
4. Click Review +Create. Once validation passes, select Create to create the virtual WAN.
In this section, we will create one virtual network in US and two virtual network AUS region respectively.
1. Click + create a resource button, select, Networking > Virtual Network
2. Enter the details to create a single virtual network with one subnet in an Australian region
3. Repeat this step for creating an additional virtual network in Australia and a new virtual network in a US region.
4. In my lab I have used 10.1.0.0/24 & 10.2.0.0/24 for Australia and 10.3.0.0/24 for the US region.
If required, please refer to the link below for assistance with this.
Create a Virtual machine.
Deploy a Windows VM in each VNet to be used for testing connectivity. Below are the virtual machine details I used in my lab:
|Azure Australia VNET01 – VM01||10.1.0.4|
|Azure Australia VNET02 – VM01||10.2.0.4|
|Azure US VNET01 – VM01||10.3.0.4|
I have assumed you are familiar with deploying virtual machines in Azure and will not show these steps below. If not, please refer to the following link for assistance with this.
Steps to create Hub with VPN Gateway:
In this section, we will create a virtual Hub with VPN gateway in Australia to use for Site to Site VPN and VNET connectivity.
1. Click on the Virtual WAN created on the earlier section.
2. Click Hubs and select +New Hub.
3. Provide required details:
• Name: Hub-aus01
• IP Address: 10.100.0.0/24 (this should not overlap with any other IP address space)
• Region: Australia East.
Figure 5: Creation of Virtual Hub
4. Click Next: Site to site.
5. Click on Yes for creating Site to Site VPN gateway.
6. Provide the scale units for the gateway based on the required VPN throughput. Note: ASN number is not editable.
Figure 6: Creation of VPN Gateway in Hub
7. Click Review + create and once validation complete select Create.
Steps to create Hub in US region:
In this section, we will create a virtual Hub in US Azure region to use for VNET connectivity.
8. Click on the Virtual WAN created on the earlier section.
9. Click Hubs and select +New Hub.
10. Provide required details:
• Name: Hub-us01
• IP Address: 10.101.0.0/24 (this should not overlap with any other ip address space)
• Region: Central US.
11. Leave other settings as default.
12. Click Review + Create and once validation complete select Create.
Steps to VPN site in Hub:
In this section, we will create a VPN site in Azure Virtual Hub.
1. Click on the Virtual WAN and select Hubs and click “Hub-aus01” created earlier.
2. Click VPN (site to site) and Hubs and select +create new VPN site
3. Select region of VPN (the same as the Hub), provide a name for the VPN and vendor name.
4. Enable BGP if required and select the appropriate Hub from the drop-down. Note: If you don’t want BGP enabled, then provide the IP address range for on-premises networks. For example, I have provided my on-premises IP address space (188.8.131.52/16) and disabled BGP.
5. Click Next: Links
6. Provide the name for the link and the VPN provider name. This can be any name but I suggest you choose something meaningful to you.
7. Enter the speed of VPN connection as integer (in Mbps).
8. Provide the public IP address of on-premise VPN device. In my lab this will be Public IP address of my windows server 2012 with RRAS options.
9. Provide BGP IP address and ASN from on-premise VPN device settings (this is optional if you enabled BGP on step 4).
10. Click Review + create and once validation complete select Create.
Figure 7: Creation of VPN site
On-Premise VPN device:
For my lab I have used a windows server 2012 R2 with RRAS settings, which will act as my VPN device.
I will not show the implementation steps below, you may refer to the links (from one of my earlier post) with sections Configure the VPN Device and Configure the S2S VPN via PowerShell for configuring VPN if you require assistance with setting this up.
Connect VPN sites and download the configuration file.
In this section, we will provide On-premises VPN details to VPN sites for connection.
1. Click Select Connect VPN Sites under virtual WAN and select VPN site created earlier and click Connect sites.
2. I left all settings as default and clicked connect.
3. Click on Download VPN config options and it will place the configuration file in an Azure storage account. Download a copy for configuring the VPN connection.
4. The file will have VPN gateway information and pre-shared key details.
5. We need to have the Public IP of VPN, the pre-shared key is required for the PowerShell script, referred in on-premises VPN device section.
6. Ensure we have configuration completed for the on-premises VPN Device (using the PowerShell as mentioned).
7. Once the settings are correct, VPN connection will be enabled as shown:
Figure 8: VPN site connected
Connect the VNet to the Hub
In this section, we will connect the virtual network to virtual Hub. This will enable connectivity between all sites and enable full mesh connectivity across regions and offices.
1. Click Virtual network connections, from Azure virtual WAN page.
2. On the new page, select +Add connection.
3. On the Add connection page, fill in with the required details:
• Connection name - Name your connection.
• Hubs - Select the Hub you want to associate (Hub-aus01).
• Resource group – select the resource group where the VNET is located.
• Virtual network - Select the virtual network you want to connect to this Hub.
4. Select OK to create the connection.
5. Repeat these steps for each VNet created as part of this lab. We need to connect 2 VNETs to Australia region and one in US region HUB.
Test the connectivity
We are finally ready to test the connectivity across all sites created as part of this lab. I have logged into the virtual machines created earlier to test network ping connectivity.
Ping test from US VM to AUS VM Region (Hub to Hub). The latency is little higher, since I have used Central US region and Australia.
Figure 9: Ping test From US to AUS region.
Ping test from AUS to US Region (Hub to Hub).
Figure 10: Ping test From AUS to US region.
Ping test from On-prem to AUS & US region (VPN to AUS Hub)
Figure 11: Ping test From On-prem VPN to AUS region.
Ping test from AUS region to On-prem (AUS HUB to On-Prem)
Figure 12: Ping test From AUS HUB toOn-prem VPN.
I hope you enjoyed this lab exercise of Azure virtual WAN and have a better feel for how to implement it to meet your own requirements.
Azure Virtual WAN can be useful in the below use cases:
- To Create a full transitive network with on-premises to all our virtual networks in Azure across regions with Express Route or VPN connections.
- We can enable restrictions to force VNETs to be isolated with route tables and have a firewall.
- Migrate existing MPLS network connectivity to Azure vWAN with Microsoft backbone network. This will provide a single pane of management for cloud and on-premise network functionality.