0

I have 2 VNETs in Azure.

AppVnet -10.0.0./24 -- Peered
Dbvnet - 10.10.0.0/24 -- Peered.

Firewall Sonic wall. Current status: VPN tunnel is created(route-based) and connected from on-prem to AppVnet and VM's on AppVnet to On-prem

peering is completed, DBvnet used a remote virtual network, and it connects with AppVnet.

The challenge. DbVnet cannot connect with on-prem and on-prem cannot connect with DBvnet.

Jon Drew
  • 1
  • 1

1 Answers1

0

You have effectively created a hub and spoke type setup here, with AppVnet being your hub, DbVnet being the spoke, and your VPN connecting your on-prem network to the hub. By default there is no transitive routing over vnet peering, so your on-prem network will not be able to talk to the DBvNet.

As per this article, you need to configure your peering connections to allow this. This mentions ExpressRoute, but the scenario is the same for VPN Gateways.

When an ExpressRoute circuit is connected into the Hub-and-Spoke design, the BGP routes that are advertised from on-prem into the ExpressRoute virtual gateway will not natively transit into the Spoke VNets. Instead, these routes will populate in the Hub VNet only. Likewise, the ExpressRoute gateway will not natively advertise Spoke VNet routes out, and instead, will only advertise the network ranges that belong to the Hub VNet. In order to allow the ExpressRoute virtual gateway to advertise routes from Hub to Spoke, you must select the “Allow Gateway Transit” option in the VNet peering panel of the Hub. And then to allow the Spoke VNet routes to transit out of the ExpressRoute gateway, you must select the “Use Remote Gateway” option in the VNet peering panel of the Spoke. Once complete, all on-prem BGP routes advertised through ExpressRoute will be visible in the Hub and all participating Spokes, and vise-versa.

Sam Cogan
  • 38,158
  • 6
  • 77
  • 113