vWAN Hub not allowing transit traffic from 3rd party NVA

Question

Routing issue with NVA VM.png

Hi Folks,

I am new to MS Azure and I am struggling with this routing issue since a day now, trying to simulate an upcoming deployment scenario in my free-tier account, please refer to the diagram attached to get more clarity on the issue, issue is described as follows:

There is BGP peering between Gi2 interface on the NVA and vHub, routes are being exchanges as expected. Linux-VM hosted in TEST-VNET is also receiving the SDWAN branch site routes.

On the vWAN hub, routes from Transit-vnet and TEST-VNET are associated and propagated in default routing table, so TEST-VNET is receiving SDWAN branch routes, and SDWAN Branch is also receiving TEST-VNET route, the only problem is that reachability between VMs in those two subnets does not exist. I am checking reachability using ping command.

After extensive troubleshooting, I can see that vWAN Hub is not forwarding the traffic from remote branch sites to TEST-VNET, be it return traffic originating in TEST-VNET or traffic initiated from branch site.

e.g. I have noticed when I try to ping a VM in Branch site from TEST-VM in Azure, the icmp-request packets can be seen at branch site, I captured them using wireshark. Also, I can see on the NVA Gi2 interface, the icmp-response traffic from Branch-VM is going towards vWAN Hub, but when I do TCPDUMP on TEST-VM, I cannot see the ICMP response packets

I have Free-Tier subscription. NVA is NOT in vHUB, there are no NSGs associated with the VMs in azure, the only one I have is associated to Gi1 on NVA router.

What am I missing here?

Answer 1

@Gaurav Sehgal

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

I understand that you are trying to configure Transit connectivity to a Spoke VNET connected to a vHUB using a custom NVA (NVA is not deployed in the vHUB and is actually in a different Spoke VNET)

Your exact architecture is documented here.

And as such, should be supported.

I suggested we check the Effective routes of the Hub and make sure Test-VNET 's Destination prefix points to the next Hop as "test-to-hub" (the VNet connection)

Further,

• It is possible that the vHub is not able to route packets to the VNET.
• i.e., there could be a route table misconfiguration on the VNET link between VNET and vHub - "test-to-hub"
• Can you please try to send traffic between "Transit-VNET" and "Test-VNET"
  • In both directions and see if that works?

You informed that the NVA NICs didn't have IP Forwarding enabled.

Enabling this resolved the issue.

Thanks,

Kapil

---

Please Accept an answer as this helps the community find answers faster by identifying the correct answer.