Scenario: spoke vnets svnet1 ,svnet2, svnet3 is connected to virtual hub NVA Vnet nvavnet is connected to virtual hub Expressroute connected to virtual hub svnet1 and svnet2 are isolated but should be reached by Express route Expectation: VM's in svnet1 should be reachable through on-prem(ER) VM's in svnet1 and svnet2 should not be reachable (Isolated vnets) VM's in svnet3 should reach VM's in snvet1 and 2 Only Internet traffic should go through nvavnet (palo alto) since the spokes vnets needs to be connected directly to vhub and only internet connection needs to go to nva vnet, I did not find any documentation with this scenario. Moreover, I see that this scenario might not be supported per below article https://learn.microsoft.com/en-us/azure/virtual-wan/scenario-route-through-nva Can you please let me know if this scenario is possible and another thing I observed is that, the vnet isolation works only if I turn off the "Propagate to default route" switch in connections. Not sure if that is the expected behavior

@SudhirKumar Sampathkumar Thank you for reaching out. Based on your question above. since the spokes vnets needs to be connected directly to vhub and only internet connection needs to go to nva vnet, I did not find any documentation with this scenario. I think this architecture is described in this article here In the Architecture described above All internet bound traffic from VNets 1, 2, and 3 is expected to go via VNet 5 NVA 10.5.0.5. For internet-bound traffic to go via VNet 5, you need VNets 1, 2, and 3 to directly connect via virtual network peering to VNet 5. You also need a user-defined route set up in the virtual networks for 0.0.0.0/0 and next hop 10.5.0.5. Which I think satisfies your requirement above. Regarding your question related to "Propagate to default route". I do not think you need enable this property as you only change this setting to Enable if you know you want to propagate the default route. As in the scenario above the default route will be applied for the VNET peering connection. Hope this helps! Please let me know if you have any additional questions. Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

It is possible to route Virtual WAN internet traffic through a third-party NVA while having spoke VNets directly connected to the virtual hub. However, the scenario you described, where some VNets are isolated and some are not, may not be supported. According to the documentation, VNet isolation works only if the "Propagate to default route" switch in connections is turned off. As for the specific scenario you described, I couldn't find any documentation that supports it. References: Scenario: Route traffic through an NVA Scenario: Route traffic through NVAs by using custom settings

Virtual WAN Internet traffic Routing via third party NVA but the spoke vnets should be directly connected to virtual hub

Accepted answer

ChaitanyaNaykodi-MSFT 23,026 Reputation points Microsoft Employee

2024-02-21T04:06:33.4666667+00:00
@SudhirKumar Sampathkumar

Thank you for reaching out.

Based on your question above.

since the spokes vnets needs to be connected directly to vhub and only internet connection needs to go to nva vnet, I did not find any documentation with this scenario.

I think this architecture is described in this article here

In the Architecture described above

All internet bound traffic from VNets 1, 2, and 3 is expected to go via VNet 5 NVA 10.5.0.5.

For internet-bound traffic to go via VNet 5, you need VNets 1, 2, and 3 to directly connect via virtual network peering to VNet 5. You also need a user-defined route set up in the virtual networks for 0.0.0.0/0 and next hop 10.5.0.5.

Which I think satisfies your requirement above.

Regarding your question related to "Propagate to default route". I do not think you need enable this property as you only change this setting to Enable if you know you want to propagate the default route. As in the scenario above the default route will be applied for the VNET peering connection.

Hope this helps! Please let me know if you have any additional questions.

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

1 person found this answer helpful.
SudhirKumar Sampathkumar 25 Reputation points

2024-02-21T16:34:03.3133333+00:00

Hi @ChaitanyaNaykodi-MSFT , Thank you for the prompt response.

In the Scenario mentioned above, the spokes vnets are peered to NVA vnet and not linked directly to virtual HUB. Our requirement is as below

spokes vnets should be directly connected to vwan hub so that we can reach the spokes vm's directly from on-prem. If we follow the peering model which you mentioned above, I believe we need to reach the VM's in spokes through the NVA vnet which is not our requirement.

spokes vnets should be isolated from each other. We were able to achieve it by associating all the spoke vnets to rt-1(route table) and did not propagate them in to the same route table. This way, we were able to achieve vnet isolation.
But for the internet traffic to go to NVA vnet, we need to enable "Propagate to default route" on all the spokes connections. Only then the internet traffic is reaching the NVA vnet. But on the down side, the isolation is not working and all spokes vnets become reachable to each other

So to conclude, we would like to know following details for us to plan the VWAN routing

Is it possible to connect the spokes vnet to virtual hub and at the same time route the internet traffic to nva vnet and preserve the spokes vnet isolation. The below diagram in the article https://learn.microsoft.com/en-us/azure/virtual-wan/scenario-route-through-nvas-custom#alternate provides the scenario of connecting the spokes vnets to vhub and at the same time route the internet traffic to nva vnet but do not cover the vnet isolation part.

Why does enabling "Propagate to default route" destroy spokes vnet isolation routing in virtual hub. We are not able to understand the exact functionality of this based on the description
"Allows Virtual Hub to propagate a learnt default route to this connection. This flag enables default route propagation to a connection only if the default route is already learned by the Virtual WAN hub as a result of deploying a firewall in the hub or if another connected site has forced tunneling enabled. The default route does not originate in the Virtual WAN hub."

ChaitanyaNaykodi-MSFT 23,026 Reputation points Microsoft Employee

2024-02-21T23:05:13.2433333+00:00

@SudhirKumar Sampathkumar Thank you for getting back.

If we follow the peering model which you mentioned above, I believe we need to reach the VM's in spokes through the NVA vnet which is not our requirement.

Yes, your understanding is correct here.

We were able to achieve it by associating all the spoke vnets to rt-1(route table) and did not propagate them in to the same route table. This way, we were able to achieve vnet isolation.
But for the internet traffic to go to NVA vnet, we need to enable "Propagate to default route" on all the spokes connections. Only then the internet traffic is reaching the NVA vnet. But on the down side, the isolation is not working and all spokes vnets become reachable to each other

I have reached out to the team internally regarding this issue and will make an update here as soon as I get a response. Thank you!

SudhirKumar Sampathkumar 25 Reputation points

2024-02-22T19:52:37.6066667+00:00

@ChaitanyaNaykodi-MSFT , thank you for the update. Awaiting response from your internal team

SudhirKumar Sampathkumar 25 Reputation points

2024-02-26T04:49:34.9233333+00:00

Hi @ChaitanyaNaykodi-MSFT , Can you let me know if if there is any update from your end.

ChaitanyaNaykodi-MSFT 23,026 Reputation points Microsoft Employee

2024-02-26T16:59:55.9166667+00:00

@SudhirKumar Sampathkumar

Thank you for your patience here. I heard back from the team.

We were able to achieve it by associating all the spoke vnets to rt-1(route table) and did not propagate them in to the same route table. This way, we were able to achieve vnet isolation.
But for the internet traffic to go to NVA vnet, we need to enable "Propagate to default route" on all the spokes connections. Only then the internet traffic is reaching the NVA vnet. But on the down side, the isolation is not working and all spokes vnets become reachable to each other

This is an expected behavior. Currently when "Propagate to default route" is enabled VNET isolation cannot be achieved. The team is aware of this behavior and discussing this in their long term plans. Currently no ETA is available.

I will work with the team and get this documented.

The product team suggested that for VNET isolation to work peer the spokes directly with the NVA VNET and add UDR on the spoke for 0.0.0.0/0 with next hop NVA.

From the architecture I had suggested above if you remove the Service VNET from the architecture and just implement the architecture with DMZ VNET only (screenshot below).

This way

Internet traffic is routed via NVA using vnet peering.

And you can directly reach the VM in spokes from the branches as Service VNET NVA is not added.

As there is no need enable "Propagate to default route" you should be able to achieve VNET isolation.

Hope this helps! Please let me know if you have any additional questions.

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

SudhirKumar Sampathkumar 25 Reputation points

2024-02-27T14:58:57.94+00:00

Hi @ChaitanyaNaykodi-MSFT , Thank you for the detailed explanation. This information will be enough for us to plan the VWAN routing. One last thing is that I would like to know more about what exactly is the functionality of "Propagate to default route". What kind of traffic does it handle and why the isolation is cutoff when this is enabled.
It would be great if you can explain with an example.

ChaitanyaNaykodi-MSFT 23,026 Reputation points Microsoft Employee

2024-02-27T16:31:42.99+00:00

@SudhirKumar Sampathkumar
Thank you for getting back.

One last thing is that I would like to know more about what exactly is the functionality of "Propagate to default route". What kind of traffic does it handle and why the isolation is cutoff when this is enabled.

Sure, let's take the example of the alternate workflow architecture you had mentioned above.

When "Propagate to default route" is enabled for the Hub connections above it acts as a catch all route (0.0.0.0/0) and it includes all VNETs. Once the packet enters the hub, the hub doesn't currently have the capability to look at associations and propagations. Which allows the VNETS to communicate with each other when this property is enabled. Hope this helps! Thank you!

SudhirKumar Sampathkumar 25 Reputation points

2024-02-27T18:25:41.35+00:00

Hi @ChaitanyaNaykodi-MSFT Satisfied with the answer. Thank you and this can be closed. Greatly Appreciate your timely help on this.
Sign in to comment

Virtual WAN Internet traffic Routing via third party NVA but the spoke vnets should be directly connected to virtual hub

1 additional answer