You might know what Azure Virtual WAN is: in essence it is a network connectivity model in Azure where you can attach your Virtual Networks, your VPN branches, your ExpressRoute sites and your remote users connecting over VPN to it, and everybody can talk to each other.
The main component of Azure Virtual WAN is the Virtual Hub: here is where you connect all those things I described in the previous paragraph. You can think of a Virtual Hub as a Virtual Network (aka vnet) managed by Microsoft with a bunch of gateways inside (Site-to-Site, Point-to-Site, ExpressRoute), and optionally an Azure Firewall to provide additional security.
Virtual Hubs map 1 to 1 to Azure regions: when you create a Virtual WAN, you deploy one Virtual Hub in each region where you want your global network to have a point of presence.
Today I was confronted with an interesting question: can you connect two virtual hubs together? If two organizations each have their own Virtual WAN, and they decide to connect both, how can that be done? Well actually it is quite simple: Virtual WAN supports VPN connectivity, so each Virtual WAN could “pretend” to be a VPN site to each other.
In this Azure CLI script I have an example of how to deploy two Virtual WANs and connect them to each other, along some Vnets to do the successful pings we all need before the weekend. If you already have other Site-to-Site VPN tunnels deployed, you already know how to get the public IP address of your gateways, and that is what you would use when defining the VPN sites. If you have no VPN configures (you are starting from scratch), just configure a bogus destination IP in the first site, you will be able to change it later.
In Virtual WAN 1 you would define a VPN site to connect to hub2 in Virtual WAN 2:
az network vpn-site create -n hub2-0 -g $rg -l $location1 --virtual-wan $vwan1 --ip-address $hub2_gw0_pip --address-prefixes $location2_summary --device-vendor microsoft --device-model vhub --link-speed 100
I call it “hub2-0” because I am connected to the first public IP (which I have in the variable $hub2_gw0_pip. You can define a second site to the second public IP of the remote site (Site-to-Site gateways are always deployed with redundancy), you can see how to do that in the CLI script. After having the site, you now connect it to the gateway:
az network vpn-gateway connection create -n hub2-0 --gateway-name hubvpn1 -g $rg --remote-vpn-site hub2-0 --enable-bgp false --protocol-type IKEv2 --shared-key "$password" --connection-bandwidth 100 --routing-weight 10 --internet-security true
And for the other direction (vwan2 to vwan1), the opposite commands:
az network vpn-site create -n hub1-0 -g $rg -l $location2 --virtual-wan $vwan2 --ip-address $hub1_gw0_pip --address-prefixes $location1_summary --device-vendor microsoft --device-model vhub --link-speed 100 az network vpn-gateway connection create -n hub1-0 --gateway-name hubvpn2 -g $rg --remote-vpn-site hub1-0 --enable-bgp false --protocol-type IKEv2 --shared-key "$password" --connection-bandwidth 100 --routing-weight 10 --internet-security true
Now, you must have noticed that I disabled BGP in the VPN connection, and if you have read my previous blogs you might have realized that I never do this. Why did I changed my mind? Well, because of an existing limitation in Virtual WAN, you cannot change the Autonomous System Number to anything other than 65,515. If you try to create a virtual Hub with some other ASN you will get an error message.
And the VPN connections need to be on eBGP, so connecting two hubs with the same ASN over BGP is a no go. I am telling to myself that this is actually a feature, not a bug: if you are interconnecting two Virtual WANs, chances are that those are different routing domains, possibly with some overlapping IP address reanges. Therefore, you want to control really tightly (read statically) what gets sent over the link between both Virtual Hubs.
Feel free to try the Azure CLI script to deploy two Virtual WANs connected to each other and let me know if you find any bug. Thanks for reading!
1 thought on “Connect two Virtual WANs to each other over VPN”
[…] workaround is creating one Virtual WAN per region, and interconnecting them via VPN (see my post Connect two VWANs to each other via VPN). However there are some drawbacks to this, such as the performance limits of traffic encryption as […]