Azure Virtual WAN P2S (User VPN) Review

Virtual WAN diagram

Azure virtual WAN is one of the new enhancements to the networking portfolio for Azure this year. The value proposition is to provide path optimisation for customers connecting to Azure or Office 365 by enabling the closest hop into the Microsoft network backbone from whatever region your office may be located. This fills the gap in locations where ExpressRoute is not available or for cheaper optimised connectivity to Azure. It provides 3 connectivity options, site-to-site VPN for branch office connectivity, point-to-site VPN or user VPN for mobile users, and ExpressRoute; and provides a hub which connects all these options together.

any to any

The real value proposition of Azure Virtual WAN is in a global reach use case where you can have one branch office in one region connect to another branch office in a different region via the Azure Virtual WAN hubs.

As mentioned in Azure Virtual WAN documentation at, Azure Virtual WAN supports the following global transit connectivity paths. The letters in parentheses map to the diagram above.

  • Branch-to-VNet (a)
  • Branch-to-branch (b)
    • ExpressRoute Global Reach and Virtual WAN
  • Remote User-to-VNet (c)
  • Remote User-to-branch (d)
  • VNet-to-VNet (e)
  • Branch-to-hub-hub-to-Branch (f)
  • Branch-to-hub-hub-to-VNet (g)
  • VNet-to-hub-hub-to-VNet (h)

I tested the point-to-site or user VPN option for Azure Virtual WAN with the OpenVPN client on my Windows 10 machine. Provisioning of the Azure Virtual WAN is easy with a few clicks via the Azure Portal. Just configure the Resource Group, location, name and type (Standard vs Basic) to get started. However, a hub is required where VPN gateways will be created. The wizard provides the options to configure the s2s, p2s or ER gateways during provisioning of the hub or you could just provision the hub first without any gateways and do that later. It does mention that creating a hub gateway takes 30 minutes so I prefer to create the hub first without any gateways. The only settings required are region, name and internal network for the hub. This network MUST NOT overlap with any existing Azure VNETs or on-premise networks that you will be connecting.

Once the hub is provisioned, the next thing is to create a user VPN configuration. There are 2 options which are OpenVPN (SSL/TLS based) and/or IKEv2 (IPSEC based). The configuration requires either Azure certificate or RADIUS authentication. Since I do not have any RADIUS infrastructure configure, I selected Azure certificate for authentication. This requires the public key of the root certificate to be specified. If you have your own enterprise certificate authority, provide any name and enter the public key of the root certificate. As this is for testing, I created a self-signed root certificate and client certificate. Microsoft provides easy instructions on how to do this at

There was one quirk when entering the public key of the root certificate and the fix is mentioned briefly in the instructions by Microsoft.

Typically, when you open a certificate in Notepad, you would see something similar to the following:

The instructions clearly state to only copy the text between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” and paste it into the public certificate field. However, if we do this, it complains that the certificate is in an incorrect data format.

This is due to the line breaks in the text. You would need to remove all the line breaks so that it becomes a single line of text in Notepad as shown below:

Copy and paste the text into the field and you should see a green tick to show that the format is now correct.

Once the configuration is created, navigate to the Virtual WAN hub that was previously created and create a new User VPN Gateway associating the user VPN configuration created in the previous step. Specify the gateway scale unit (bandwidth) in increments of 500 Mbps and the client address pool which will be allocated to VPN clients. Again, this network range must be unique.

This step will take 30 minutes to complete. While waiting, you can download the VPN configuration to be used in the OpenVPN clients. Go to the User VPN configuration section and click on “Download user VPN profile”, select the authentication type and click on the “Generate and download profile” button to download the configuration zip file.

The downloaded configuration zip file contains 3 folders, AzureVPN, Generic and OpenVPN.

If using the OpenVPN client, open the OpenVPN folder where you will find the “vpnconfig.ovpn” configuration file. Copy this file into the OpenVPN client configuration directory. Follow the instructions from to extract the private key and client certificate into a file and copy it into the vpnconfig.ovpn file.

If you are connecting to a resource (virtual machine, etc) in your Azure subscription, select “Virtual network connections” and connection to the VNET in your Azure subscription where the resource resides.

There was a strange error that I received when provisioning the VPN Gateway where it would return a “Failed ” status after 30 minutes or so. I tried deleting and re-creating the gateway multiple times trying different IP ranges for the clients (suspecting an IP subnet overlap) but still getting the same error.

The Virtual Hub overview page showed the same error:

Looking through the Activity Log, the error received in the logs weren’t exactly descriptive with the “Internal Server Error” message.

However, I thought I would just try connecting anyway and to my surprise, the client connected with no issues. The status even showed the connected client and data being transferred.

Logged a case with Microsoft support and they found that the backend systems and the portal was not in sync. The fix was to run the following command in Azure Shell (Powershell) to sync the portal with the backend systems.

PS Azure:> Update-AzP2sVpnGateway -ResourceGroupName <resource group name> -Name <User VPN Gateway>

Connected another VNET to the Azure Virtual WAN hub and the VPN client picked up the new IP subnets straight away without having to disconnect.

I then successfully connected to the private IP of my Windows server virtual machine in Azure from my Windows 10 client via RDP. I then disabled the Windows firewall temporarily and tested pinging my Azure VM from the VPN client.

Ping response times averaged around 28 ms. My Azure VM is located in Australia East (Sydney) and my client machine is located in Sydney as well. As a reference, if I run Ookla Speed Test from the same client, I get 16 ms ping times to Chatswood from Sydney.

As Azure blocks pings over the internet except for VPN and ExpressRoute connections, the only method of comparing apples-for-apples between Azure Virtual WAN and the internet is to perform a port ping. Sysinternals provides a utility called “psping” which can be used to ping any port.

Performing a port ping over the internet to a public IP on my Azure VM showed latency of approx. 21 ms.

If I run the same port ping over the VPN link to my Azure VM’s private IP, the latency is about the same, actually slightly more due to the overhead for the VPN link.

This is expected as the VPN connection is also through the internet unless you have dedicated link such as ExpressRoute.

You can also configure a global VNET peer with a VNET from a different region to the Azure Virtual WAN hub. However, you will need to register the “AllowCortexGlobalVnetPeering” feature of the Microsoft.Network provider namespace first. This is mentioned in the following article:

If you do not register the feature first, you will receive an error with status message “NoRegisteredProviderFound” as shown in the activity logs.

It does take approx. 15 minutes to register the feature. Run the following command to check the status of the registration.

The next test performed involved psping tests from my client VPN in Sydney to another Azure VM in Australia Southeast (Melbourne). The same Azure Virtual Hub as before (in Sydney) is used and a global VNET peer is created from the hub to the Australia Southeast VNET where the other VM resides. The results of the psping tests to the VM via the public internet to it’s public IP and via VPN to it’s internal IP yielded the similar latencies.

Connectivity via Virtual WAN VPN to internal IP of the VM in Melbourne
Connectivity via internet to the public IP of the VM in Melbourne

As a final test, I provisioned a new Windows 2019 VM in East US region and tested from my VPN client in Sydney.

Running the same psping.exe test again showed similar results.

Connectivity via internet to the public IP of the VM in East US
Connectivity via Virtual WAN VPN to the private IP of the VM in East US

In fact, in all 3 tests to where the target VMs were in different regions (Sydney, Melbourne and East US), the latencies over the Virtual WAN VPN were slightly higher probably due to the VPN overhead.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.