Thank you for getting back.
I am summarizing the discussion above before providing the answer to your follow-up question.
In order to resolve the routing internet traffic via NVA, you peered the VNETS with VNET containing the NVA and traffic flow was established as shown here.
Regarding your follow-up question above
All routes learned from Site to Site VPN are directly injected into Connections. So next hop for remote site subnets, is being sent to hub IP and not to azure firewall. If we route it to Azure firewall by adding a custom route for remote sites subnet to Azure FW, traffic is broken.
The reason for this might be as documented here in this scenario. As the VNet and branch connections are associated and propagating to the default route table. Although the hubs are secured (there is an Azure Firewall deployed in the hub), they aren't configured to secure private or Internet traffic. Doing so would result in all connections propagating to the None
route table, which would remove all non-static routes from the Default
route table and defeat the purpose of this article since the effective route blade in the portal would be almost empty (except for the static routes to send traffic to the Azure Firewall).
how to make sure that routes learned from VPN in virtual hub are not directly passed to Vnets? Or how to transfer them to azure firewall?
I think the solution here would be to implement a scenario described here where you can use a route table to use Azure Firewall for VNet-to-Internet/Branch and Branch-to-VNet traffic flows. Where the route table associated with the Virtual Networks is configured in this way.
Then create a route to activate VNet-to-Internet and VNet-to-Branch: 0.0.0.0/0 with the next hop pointing to Azure Firewall. I think this will rt-01 route table in your case above.
Hope this helps! Please let me know if you have any additional questions. Thank you!
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.