How to setup Global VNet peering in Azure



Now that Global VNet peering has gone to GA I had a large university in California ask how to set this up.

What is Global VNet peering?

Global VNet peering in Azure is the ability to peer VNets or virtual networks across regions (see regional availability below).

image

Some benefits of Global VNet peering include:

  • Private Peering traffic stays on Azure network backbone
  • Low latency and high bandwidth VNet region to VNet region connectivity
  • No more VNet to VNet VPN configuration which means no VPN encryption, no gateways, no public internet necessary
  • No downtime setting up Global VNet peering with portal or ARM templates

What are some limitations of Global VNet peering?

You cannot use Global VNet peering to communicate with VIPs of load balancers in another region. VIP communication requires source IP to be on the same VNet as the LB IP:

  • Resources in one virtual network cannot communicate with the IP address of an Azure internal load balancer in the peered virtual network. The load balancer and the resources that communicate with it must be in the same virtual network.

This is a big one as it bit us with a customer. You must not check ‘use remote gateways’ or ‘allow gateway transit’ like you select when setting up intra regional VNet peering:

  • You cannot use remote gateways or allow gateway transit. To use remote gateways or allow gateway transit, both virtual networks in the peering must exist in the same region.

VNet Global peerings are not transitive meaning downstream VNets in one region cannot talk with downstream VNets in another region.


How do I setup Global VNet peering?

It is fairly straightforward to setup Global VNet peering and I documented the steps below:

1) Setup VNets in each region you want to Global VNet peer. There are a few Global VNet restrictions for regions see here for region restrictions. In my case, I created a VNet in US West 2 and West Central US

2) For testing create a VM in each region and associate it to a VNet you are going to use with Global VNet peering to test VM connectivity. The VMs cannot be associated with a downstream VNet as you recall since transitive downstream VNets are not supported with Global VNet peering.

3) Enable Global VNet peering:

3a) On one of the VNets you want to Global peer, go to Peerings and click Add

image

3b) Fill out the peering and select the VNet in the other region you want to Global Peer with – Important – don’t check any of the checkboxes!

image

3c) Setup peering in other direction by repeating step 3a and 3b but with the VNet peering in the other region – also don’t click any checkboxes and pick the other VNet in the other region you want to Global peer with:

image

4) Let it finish provisioning and then validate VNet Global peering is Connected on both VNets:

image

image


5) Test Global VNet connectivity with Telnet, PSPing or Ping Note: ensure firewalls allow ports you are telneting to, ICMP, etc.:

Test connectivity from one direction:

image

Then test connectivity from the other direction:

image

6) You are done! Congratulations Global VNet peering is complete! 

7) Optional – If you need reduced latency between the regional VNets you can optionally enable Virtual Machine Accelerated Networking for Windows or for Linux


Comments (2)

  1. “You cannot use remote gateways or allow gateway transit” with Global Peering. I was just setting it up and ran into this issue. I would replace my VNet-to-VNet connections and the Virtual Network Gateways in all regions with Global VNet Peering, but when I can’t use the gateway connecting to our HQ it is not possible. Will that be supported, and when? Without allowing gateway transit Global VNet Peering is of no use in our scenario.

    1. markga says:

      I am not sure if Global VNet peering will ever support ‘allow Gateway transit’ or ‘remote gateways’. Your alternative to Global VNet peering is to continue to use VNet to VNet VPN combined with intra regional peering. Here is the documentation:

      Gateway transit is not supported in the peering relationship between virtual networks created in different regions. Both virtual networks in the peering relationship must exist in the same region for gateway transit to work.

Skip to main content