Deploy Azure virtual WAN in 2,5 Hours

With Azure virtual WAN at the current point of maturity, I noticed more and more landing zone deployments based on virtual WAN are coming up. Both in the greenfield and for migration.

Currently, I do around one to two landing zone deployments. That brought me in the position to be very efficient and I’m able to deploy the landing zone in around 2,5 hours.😊 Let’s go together through the process and see how you can do it too. 

Target landing zone

First, let’s discuss the landing zone I deployed with my customers. It is a very simple one for PoC and testing purposes, but it can scale out for more productional use cases.

The landing zone consists of:

• • One Resource Group for the virtual WAN Components

• • Two Resource Group for Virtual Machines and their connected resources incl. Virtual Network for the spoke, one per region

• • One Virtual Network Hub Resource

• • Two Virtual WAN Hubs in two regions

• • One VPN Site 2 Site Gateway and one Point to Site Gateway per hub

• • Point to Site VPN profile with Azure Active Directory Authentication

• • A site to site VPN config

• • Two virtual Networks, one per region

• • One VM per region in the spoke VNet

From an architectural perspective, it would look like shown below.

After the deployment, you can enhance the architecture in the following way.

• • You can now add DNS and Active Directory Services to the VMs

• • You can enhance the Network Security Groups in the Spoke to improve network security

For testing purpose, you can then test the following scenarios.

• • Connect from a User / Point to Site VPN tunnel to:

• • • On-Premises via VPN

• • • Access the Azure VM in Spoke Region one and Region two

• • From Site to Site VPN

• • • Access the Azure VM in Spoke Region one and Region two

• • From Azure VMs

• • • Access to the VM in the other Spoke

• • • Reach Resources and Services On-Premises via VPN

Creating the same environment with classic hub and spoke takes around one week and I would need to have at least one Network Virtual Appliance or Router VM in the hub network.

Deployment of the landing zone

The next steps are exactly what you need to do to deploy the landing zone:

• • Create the Resource Groups

• • Deploy the virtual WAN Hub resource

• • Integrate the Azure VPN Client into Azure Active Directory

• • Create the Point to Site VPN Profile

• • Create the Virtual WAN Hubs

• • Create the Site to Site configuration

• • Create the Spoke virtual Networks

• • Create the Test VMs in both spokes

• • Connect the Spokes to the Hubs

• • Connect the VPN Site to the Hub

I would suggest opening at least three tabs with Azure Portal to switch back and forth during the deployment, for a smooth experience. 

 

Create the Resource Groups and deploy the Virtual WAN Resource

As already mentioned, the first step is to deploy the resource groups for our virtual WAN landing zone. I personally prefer to have a dedicated Resource Group for virtual Wan because there are many hidden resources added to that resource group and I don’t like to mix up virtual WAN infrastructure with other services and components.

I will also add two resource groups for my landing zone virtual Network and the connected VMs. There will be one resource group per region holding the resources for the virtual machine and virtual network, as well as the network security group.

In MS Docs you can find a guide on how to deploy a resource group in Azure. 

After you deployed the resource groups, it should look like the screenshot below.

After the resource group was deployed, we will deploy the virtual WAN Resource to our virtual WAN Resource Group. Here’s MS’s documentation on using azure virtual wan to create site-to-site connections. 

When you deploy the virtual WAN Hub Resource there are a few things to know.

 

Aside from using the right Subscription and Resource Group, you need to select the Resource Location.

In virtual WAN you can deploy virtual WAN resources everywhere in the Microsoft Azure Regions, but the resource file is only located in one region at the time being. If that region goes down, your virtual WAN will still be operational, but you cannot change its configuration.

As a result, you deploy the virtual WAN Resource in a larger region like West Europe, North Europe, Southeast Asia, West US etc. Avoid small local regions like France Central, Korea etc.

Then, you have the Type of Virtual WAN where you can decide between Basic and Standard. Basic is a highly available and highly scalable VPN Gateway in a Hub and Spoke architecture but does not provide features like ExpressRoute Gateway, Hub to Hub transit, Point to Site Gateway, VNet to VNet transit, Azure Firewall or NVA in the Hub.

Virtual WAN type	Hub type	Available configurations
Basic	Basic	Site-to-site VPN only
Standard	Standard	ExpressRoute User VPN (P2S) VPN (site-to-site) Inter-hub and VNet-to-VNet transiting through the virtual hubAzure FirewallNetwork Virtual Appliances

The virtual WAN Hub Resource deployment can take up to 10 minutes. We can change the browser tab or windows and move on with the next step of our deployment in the meanwhile.

Integrate the Azure VPN Client to Azure Active Directory and create the Point to Site Profile in Virtual WAN

The next step is to integrate the Azure VPN client to Azure Active Directory to prepare your Point to Site profile integration. We will later use Azure AD VPN authorization with Azure AD. That makes it easy for users to log on and use their Azure Single Sign-On Credentials. Have a read through the MS documentation about VPN Gateway: Azure AD tenant for P2S VPN connections: Azure AD authentication and Configuring Azure AD authentication for User VPN connection: Virtual WAN.

First, we need to get the Azure VPN Enterprise App into our Azure Tenant. Use the registration link.  Azure Public uses the following link. After you registered the Azure VPN Client you should be able to find it in the Azure AD.

 

Now we need to copy two things for the next step. First is the application ID of the Azure VPN Enterprise App. Copy it to an editor of your choice. You will need it later.

Add a group, or users to the Azure VPN App, so that they can access the Point to Site later. In production environments, you should use groups and conditional access to improve remote security.

With Azure Active Directory Free, you need to apply single users to the VPN Enterprise app. With a higher Azure Active Directory SKU like P1 or P2, you should create a Group for VPN users, add that group and only manage users through that group. Check out Microsoft’s guides to create or edit a dynamic group and get status – Azure AD and create a basic group and add members – Azure Active Directory.

 

The second thing you need is the Tenant ID of your Azure AD. You can find it on the overview page of Azure AD. Copy it to the editor too.

 

Now go back to your virtual WAN Resource. It should be deployed.

Create the Virtual WAN Hubs

Now we will create our hubs. Here I normally suggest a /23 CIDR or slightly larger subnet. A /23 will allow you to deploy all current resources with all scale units and give you enough space for what comes in the next releases. Check out this Tutorial: Use Azure Virtual WAN to Create Site-to-Site connections.

Within the virtual WAN hub, we will deploy the following components:

• • VPN Gateway for Site 2 Site

• • VPN Gateway for Point 2 Site

I will only deploy the minimum available scale units. In your case, please deploy whatever bandwidth or user VPN amount is necessary.

First the basic settings. Select the Azure Region where the hub should be deployed to. Always try to choose the nearest region to your offices. If you have a wide footprint, I personally recommend deploying several smaller hubs instead of a single large hub.

 

Select the appropriate Site 2 Site VPN scale units for your workload in that region.

Now move on to the Point to Site blade. Select the number of scale units, decided by the number of users connected at one time. Add an address pool for the clients and the DNS server which the clients should use. You can either use a DNS Server located in Azure or on-prem. It is recommended to use a DNS Server located in Azure. Those DNS servers must be reachable from the virtual WAN hub.

 

Next, we need to create a Point to Site Configuration. Please click create new like shown in the picture.

If you have one already, you can just select it from the drop-down menu. The “create new User VPN configuration” blade will open. You can have only one configuration per hub. I personally prefer Azure AD Authentication. For the Azure AD authentication please select Tunnel Type “OpenVPN”.

 

Switch to Azure Active Directory blade. Here we need to add a few things.

In the Audience field, add the application ID. For the Issuer and AAD Tenant we need to create two links.

The Issue should look like this https://sts.windows.net/<AAD -Tenant-ID>/ and the AAD Tenant should look like https://login.microsoftonline.com/< AAD -Tenant-ID>

NEVER add “/” at the end of the AAD Tenant link and don’t use the Tenant ID without the links created. That will result in a deployment failure.

You can add ExpressRoute Gateways, if necessary, too.

You can also add tags if needed. After you completed all the steps, please click “review and create”.

The deployment will take around 45 minutes per hub, we will now use the time to deploy our spoke network and VMs.

The hub deployment is completed if you can see following indications in the Hub Blade.

Hub Status = Succeeded (means the underlaying VNet is deployed)

Routing Status = Provisioned (the virtual Router was deployed in the hub)

Gateway provisioning status = succeeded (gateway scale units were deployed and peered with the hub router)

Create the spoke network and virtual machines

Creating a spoke Virtual Network and a Virtual Machine is common, and we will repeat the steps within that guide. Again, you should decide on an IP Mask, I would suggest a size /25 CIDR or above. A /26 CIDR per service would be necessary if you want to add services like Azure Bastion, Azure Service Endpoint or Azure Private Link.

As for my VMs, I will choose B-Series VM to save some budget. If you want to deploy applications, domain controller etc. on to the VMs, please follow the recommendations for these applications.

Here you can find an example for Microsoft Windows Server Active Directory Domain Services. You can find video guides on how to create a virtual network – Azure portal – Azure Virtual Network and how to create a Windows VM in the Azure portal.

Now the Virtual Machines should deploy for around 30 minutes depending on the size and operating system.

Create the Site to Site VPN configuration

The next step would be to deploy the first VPN Site configuration. Here‘s a guide in MS docs about that.

Virtual WAN has a nice feature called IPSec over FQDN. It is not necessary to have a static IP for your VPN Site, you can just use a dynamic DNS service or create your own on Azure. I found a great guide from Cirrius Tech to create one.

After the VPN Site was created, you normally have 15 minutes biological break to refill your coffee or get a snack.

Connect the Spokes to the Hubs and connect the VPN Site

In the meantime, our hubs and VMs should be deployed. To ensure, please check the hub status. As shown in the screenshot below, your hub components should have the following status:

• • Hub Status: Succeeded

• • Routing Status: Provisioned

• • VPN (Site to Site) Gateway: Succeeded

• • VPN (Point to Site) Gateway: Succeeded

As soon as your hub has succeeded deployment, you can start connecting your spokes. Here’s an MS tutorial about using Azure Virtual WAN to Create Site-to-Site connections.

If you want to connect to a spoke within another tenant, you need to do that via CLI. It is not possible to do it via GUI now. Here’s a MS guide on how to connect cross-tenant VNets to a hub:PowerShell – Azure Virtual WAN.

After 5 minutes, you can check the virtual NIC of the Virtual Machines in Azure and there you should see all routes and networks connected to the hub.

After you connect the spokes, you can connect your VPN Site to the Hub. Here you can find an MS tutorial on it. 

When configuring a remote site you have different options, you can have a managed device like with FortiNet or Pala Alto. They can automate their deployments. I will link some of the guides below.

• • Palo Alto Automated Deployment

• • FortiGate Deployment

• • Barracuda Deployment

If you have a vWAN unmanaged device, like a Ubiquiti Dream Machine or Security Gateway please refer to my older blog post.

Now you should have a landing zone in place and proceed with testing.

How to test?

After you deployed the Landing Zone you should establish a circle of tests to ensure your deployment works as expected.

The first test would be to connect from a client to your virtual WAN hub using Point to Site VPN. From the hub, you connect to both virtual machines in Azure and to a system on-prem to test the connectivity.

After a successful Point to Site test, you log on to a virtual machine on-prem and try to reach both virtual machines in Azure.

With that test done, you log into both Azure virtual machines and try to reach several on-premises systems.

When all tests are successful, you have a well connected and working basic landing zone to build on top.

Do you prefer scripting?

To be honest, I’m not a good scripter and virtual WAN itself is primarily UI and Portal focused but luckily my colleagues from FastTrack, Igor Pagliai and Ben Hummerstone from Azure created a basic Bicep script to deploy a similar landing zone.

There are also different Azure Resource Manager Templates for the deployment of Virtual WAN.

Any to any routing ARM template can be found here Quickstart: Create an Any-to-any configuration using an ARM template – Azure Virtual WAN.

An ARM template for a shared service hub infrastructure can be found here Quickstart: Route to shared services using an ARM template – Azure Virtual WAN.

On GitHub:

azure-quickstart-templates/201-virtual-wan-with-all-gateways at master · Azure/azure-quickstart-templates (github.com)

azure-quickstart-templates/301-virtual-wan-with-route-tables at master · Azure/azure-quickstart-templates (github.com)

Some good practices before you leave

After a successful deployment, you should do some cleaning and you should enhance your configuration.

Configure basic network security

You should not run without proper network security. The most basic security is to deploy a Network Security Group per Subnet. Create, change, or delete an Azure network security group

Deploy DNS and Directory Services

To establish a proper DNS and Directory Services infrastructure, you should now use or deploy virtual machines to host DNS/BIND and LDAP or Active Directory.

After you deployed the DNS service, you need to configure the DNS Servers into the virtual Network configuration like shown below.

You would also need to add the DNS Servers to the Point to Site client configuration.

Establish Azure Monitor and Security

To not be blind sighted on what is going on in your environment, you should start to onboard yourself and your environment to Azure Monitor and Security Center.

That would enable you to establish proper monitoring and be aware of security risks and optimizations.

Monitoring Virtual WAN – Logs and metrics – Azure Virtual WAN | Microsoft Docs

Monitoring Azure Networks – Azure Monitor Network Insights – Azure Monitor | Microsoft Docs

Monitoring Azure in general – Azure Monitor documentation – Azure Monitor | Microsoft Docs

Azure Security Center – What is Azure Security Center? | Microsoft Docs

With these small little addons, you now have a proper landing zone for your migration.

Securing Point to Site connection

To secure point so site VPN connections, you should not only rely on username and password. Define conditional access policy for your VPN client devices as soon as you can. A good practice is to check if the client is compliant with your Mobil Device Management policies and if for example cooperate certificates are installed on the system. That helps you lock out users who are not fulfilling your minimum-security standards.

You can learn more about access following this link What is Conditional Access in Azure Active Directory? | Microsoft Docs

Conclusion

As I already wrote in the introduction, I wanted to give you a guide to deploying a virtual WAN landing zone within 2,5 hours. I hope that worked out and you can use the landing zone for your Azure migrations.

If I missed something, you have questions or if you want to have more of those guides, please leave me a comment.