Azure vWAN - lost connection during creation peering with custom RT

Maciej Rybak 20

HI Azure Community

We have Virtual WAN with two HUBS , one in US and one EU. In US HUB we have seven Vnets peered to the HUB/Firewall and all traffic is going via AzureFW. Everything is working with default RT. (there is only route 0.0.0.0/0 to Azure Firewall)

Now for new project we created new, dedicated vnet and we want to peer to the same Hub/Firewall but with custom route table. With current configuration (also only routing 0.0.0.0/0 next hop same AzureFW) we lost all communication for this seven Vntes. (even If there is independent vnet and route table).

Can you help me with that? I guess there is something wrong with that RT/routing.

I didn't configure it and I have some assumptions why it doesn't work but I wanted to ask you for advice

Thank you

Maciej Rybak 20 Reputation points

2024-08-21T10:13:40.3233333+00:00

Forgot add that there is sd-wan router and we don't wan to communication between default RT and custom RT , it should be completly separated RT's.
Rohith Vinnakota 315 Reputation points Microsoft Vendor

2024-08-23T12:15:43.0033333+00:00

Hi Maciej Rybak,

Can you please share more details on the issue so that we can assist you further on this.

Does the custom route table have any routes that might conflict with the routes in the existing VNets?

What specific routes are configured in the custom route table for the new VNet?

Have you checked the effective routes for the existing VNets after introducing the new VNet with the custom route table?

Thanks,
Rohith Vinnakota
Maciej Rybak 20 Reputation points

2024-08-23T13:28:37.4033333+00:00

Hi ,

Thanks for your replay ,

No no ,

There is default RT with associated and propagated 7 Vnets , (but in effective routes we can also notice BGP routings from sd-wan.)

and custom RT calls "DMZ" - at the moment there is nothing.

When I creating virtual network connection (vWAN) for Vnet OpenAI (new project) and associate this vnet to custom DMZ RT we lost all connections for Vnets from default RT.

Both RT's default and caustom DMZ have the same routing : 0.0.0.0/0 to Virtual Appliance what if Azure Firewall

I'm not sure that it can be sd-wan reason , but there is some whey configure that somehow ?

Thanks
Maciej Rybak 20 Reputation points

2024-08-23T13:45:20.99+00:00

Both RT's default and custom DMZ (on virtual HUB) have same routes: 0.0.0.0/0 to vitual appliance - Azure Firewall.
Maciej Rybak 20 Reputation points

2024-08-23T15:42:53.9566667+00:00
Every point I would agree with you except this:

Route Propagation Settings:

Confirm that route propagation settings are correctly configured. Ensure routes are advertised properly between VNets, including both default and custom routes.

we want to isolate our OpenAI vnet (custom RT) from the rest our Vntes (associated to default RT),

so Should we set propagation(vnet connection) to None or what we can do that ? And how to set propogation on custom route table ?
Rohith Vinnakota 315 Reputation points Microsoft Vendor

2024-08-23T17:32:23.6266667+00:00
Hi Maciej Rybak

Hope this helps. Do let us know if you any further queries.
To configure route propagation to None for a custom route table .

use the following Azure CLI command:

az network vhub route-table update \ --resource-group <YourResourceGroup> \ --vhub-name <YourVirtualHubName> \ --name <YourCustomRouteTableName> \ --propagated-route-tables None

This command ensures that your custom route table does not receive or propagate routes from the default route table, effectively isolating your OpenAI VNet from the other VNets.

Thanks,
Vinnakota Rohith

If this answers your query, do click "Accept Answer" and "Upvote it." for was this answer helpful. And, if you have any further query do let us know.
Rohith Vinnakota 315 Reputation points Microsoft Vendor

2024-08-26T03:00:05.47+00:00

Hi Maciej Rybak,

Hope you are having a great day.

Just checking in to see if you have got a chance to see my response to your question in resolving the issue.

Looking forward to your response.
Thanks,
Vinnakota Rohith
Maciej Rybak 20 Reputation points

2024-08-26T09:49:24.7333333+00:00

Hi , yes thank I think we did it but not with script , just via Azure Portal but yeah is ok L( Thank you.

On more question to you , it is normalm behavior when we try to reach ICMP from virtual machine via AzureFW and we can't ? (but only to the Internet , internal icmp/ping is working) .
I'm asking because maybe it is related to our RT changes

Thank you
Rohith Vinnakota 315 Reputation points Microsoft Vendor

2024-08-27T01:26:12.8833333+00:00

Hi Maciej Rybak,
Yes, this is the expected behavior. By default, Azure Firewall blocks ICMP traffic to the internet for security reasons, but it operates correctly internally. To allow ICMP traffic, we need to create an allow network rule.
Thanks,
Rohith
If this answers your query, do click "Accept Answer" and "Upvote it." for was this answer helpful. And, if you have any further query do let us know.

Accepted answer

Rohith Vinnakota 315 Reputation points Microsoft Vendor

2024-08-23T15:28:09.9466667+00:00
Hello Maciej Rybak,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here

Custom Route Table Configuration:

Ensure the custom route table (DMZ) is correctly configured to route traffic to the Azure Firewall.

Association of Custom Route Table:

Associate the custom route table with your new VNet. Make sure the new VNet is correctly associated with the custom DMZ route table.

Peering Configuration:

Verify that the new VNet is peered with the existing VNets through the Virtual WAN hub. Check the peering setup between the new VNet and existing VNets.

Route Propagation Settings:

Confirm that route propagation settings are correctly configured. Ensure routes are advertised properly between VNets, including both default and custom routes.

Azure Firewall Rules:

Update Azure Firewall rules to handle traffic from both the existing VNets and the new VNet. Ensure rules are updated to accommodate traffic from the new VNet.

Connectivity Testing:

Test connectivity between VNets to ensure all VNets can communicate as expected.

Monitoring and Adjustments:

Monitor network traffic and route tables for any issues or conflicts. Adjust configurations as necessary based on observed performance or connectivity issues.

Additional Considerations:

BGP Routes: Since you mentioned BGP routes from SD-WAN, ensure that these routes are not conflicting with your custom route table settings.

Route Table Overlaps: Check for any overlapping routes between the default and custom route tables that might be causing conflicts.

Kindly let us know if the above helps or you need further assistance on this issue.

If you have any further queries, do let us know. If the answer is helpful, please click "Accept Answer" and "Upvote it."
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure vWAN - lost connection during creation peering with custom RT

0 additional answers

Your answer