VNet Peering Dependancy On VNG

Coughlan, Garry 1 Reputation point

I have a Hub and Spoke VNet topology configured in my Azure tenant, all spokes are peered to a central hub vnet. My Hub vnet hosts my VNG (which I use to connect back in on-prem) as well as other central infrastructure (checkpount nvas, app gateways etc). I recently upgraded the VNG sku (to increase HA and make it zonally aware). The upgrade went smoothly but one of the symptoms of the upgrade is communication between my spokes and the central hub went offline during the upgrade. Note, this communication does NOT use the VNG , but it was still impacted by the VNG upgrade. Once the new VNG came up, the communication from spoke to hub came back. So my question is, does anybody know why a VNG going offline (which it did naturally as part of my upgrade) would impact communication between my spoke vnet and my hub vnet, even if the communication was not using the VNG?


Azure VPN Gateway
Azure VPN Gateway
An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
1,401 questions
{count} votes

3 answers

Sort by: Most helpful
  1. Coughlan, Garry 1 Reputation point


    Our spoke vnets are peered into a central hub using vnet peering. The spoke vnets are not peered with each other. Diagram attached.
    The X represents the dropped connection back on-prem. The ? represents the dropped connection between spoke and hubs, even when they are not using the VNG.!

    Please let me know if you need more details.



  2. Coughlan, Garry 1 Reputation point

    We upgraded the VNG from Basic to VpnGw1AZ. Our confusion is that inter-vnet communication that does NOT use the VNG was impacted when the VNG was taken offline to upgrade.
    One other point to note... in each of the spokes, in the peering config, the VNG setting is set to "Use the remote virtual network's gateway" ie use the VNG in the hub vnet. My understanding of this is if the spoke needs to get back to an on-prem system or resource, it will traverse the VNG in the hub to do so. Our inter-vnet communication does not need to come back on-prem so this should not be relevant - I am providing this just to give more background information. Thanks.

  3. SaiKishor-MSFT 17,211 Reputation points

    @Coughlan, Garry I reproduced this setup with a Basic VPN GW a Hub vnet and a Spoke vnet peered and spoke using remote vnets GW. I then deleted the Spoke Vnet GW and created a new VNET GW for the Spoke with SKU-VpnGw1 (I deleted and created a new one as its not supported to upgrade basic SKU directly). In the entire process of doing this, there was a ping going on between the VMs in the Hub and Spoke and it did not fail.

    0 comments No comments