Problem with VPN site-to-site, app container in a subnet in a vnet peering

Question

I have a small problem with the VPN tunnel that was configured with the Virtual Network Gateway resource.

I have 3 resource groups, the GLOBAL resource group is where the Virtual Network Gateway is hosted and it is linked to the 2 resource groups RG-A and RG-B in Hub-Spoke mode.

The tunnel allows me to connect from my on-premise site and I access the elements in the RG-GLOBAL and the resource groups RG-A and RG-B that are within the DEFAULT subnet.

I created a VM in each resource group to confirm connectivity in each subnet, but note that I only access the resources if they are within the default subnet. If they belong to another subnet, the resource becomes inaccessible.

For example, my App Containers are in the infrastructure subnet. And I cannot access them from my on-premise site; but if I put them in the default subnet, access is possible.

What do I need to configure so that, without changing the subnet, the resources are accessible from my on-premise site?

Answer 1

@Mario E. Esteves Mariño

Based on your question above as only the default subnet on hub and spoke Vnets is reachable from on-prem.

• Confirm if there is route table associated with the default subnet and if you need to associate the route table with other subnets. You can go through this VPN gateway transit for virtual network peering guide to check if there was any missed configuration.
• Confirm if any NSG is blocking the connectivity. To test this you can deploy a test VM in the infrastructure subnet and use IP flow verify to check if any NSG is blocking the connectivity.
• Further to help isolate the issue you can simultaneously perform a Packet Capture on the VPN Gateway and the on-prem router to check if you observe any packets from the other subnets.

Thanks

Answer 2

Good afternoon,

Thank you very much for your reply. Indeed, that's what I did. I created a virtual machine in each resourcegroup and in each subnet of the virtual network of that resourcegroup. It didn't work until I modified the networks of my firewall (yes, it wasn't enough to just create the total networks of the Virtual Network but also of each subnet). I had to create 12 networks (4 for each Virtual Network) and I was able to reach the VM of each resourcegroup from my OnPremise site.

Additionally, I created a DNS table in my firewall to allow me to resolve the domain name of the Kubernetes cluster that is generated from the Azure Container Environment and the problem was solved.