Keeping VPN Gateway at hub as well as on Spokes

Question

Can we keep VPN gateway at both Hub and Spokes and route all traffic from the Hub?

In my current scenario - i have peered Hub and spoke.

Scenario 1 - In the case of VPN gateway only at Hub level.

I can connect the VPN of Hub and access my spoke databricks.

but on the second scenario

Scenario 2:

VPN Gateway at both spoke and hub level.

In the case of spoke with the VPN gateway configured, It is not allowing me to use "Use remote virtual network gateway or route server" under VNET peering.

And when i am trying to access the spoke data bricks, after connecting with the HUB VPN, the data bricks URL is timeout/not getting resolved.

Can you suggest if the approach is correct?

Answer 1

Hello @Ashwani kumar ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand that you would like to know if you can keep VPN gateway at both Hub and Spokes and route all traffic from the Hub.

Per design and as described in our official doc,

Each virtual network, including a peered virtual network, can have its own gateway. However, when you configure the gateway in the peered virtual network as a transit point to an on-premises network, the virtual network that is using a remote gateway can't have its own gateway. A virtual network could have only one gateway, the gateway should be either local or remote gateway in the peered virtual network.

Refer: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview#gateways-and-on-premises-connectivity

Traffic is not transiting your peered spoke VNet because of the VPN gateways deployed in both VNets. Traffic will transit a peered Vnet only if one of the VNet has VPN gateway deployed.

So, if both the peered Vnets have their own VPN gateways, the gateway transit will not work, and you won't be able to connect to your on-premises networks from the peered Vnet. This is by design. For this to work, you need to remove the VPN gateway from the peered remote Vnet, or you can remove Vnet peering and create a Site-to-Site VPN connection between both the Vnets where VPN gateways are deployed.

To resolve this issue, I would advise you to follow the below:

Either:

• Delete the VPN gateway from spoke Virtual Network.
• Peer Hub Vnet & spoke Vnet and then use the transit gateway feature in the Vnet peering as you had in scenario 1.

OR:

• Disable the Vnet peering between Hub and Spoke Vnets.
• And create a site-to-site (IPsec) connection between the two VPN gateways.

Refer: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal#site-to-site-ipsec

When you follow the Site-to-Site IPsec steps, you create and configure the local network gateways manually. The local network gateway for each VNet treats the other VNet as a local site. These steps allow you to specify additional address spaces for the local network gateway to route traffic. If the address space for a VNet changes, you must manually update the corresponding local network gateway.

Kindly let us know if the above helps or you need further assistance on this issue.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.