ExpressRoute / vWAN / Azure Firewall - Traffic timeout after withdrawing public route advertisement

Question

ExpressRoute / vWAN / Azure Firewall - Traffic timeout after withdrawing public route advertisement

Nassim Cherifi 75

Hello,

I'm trying to understand a routing behavior we observed during a DRP test.

Our initial setup was the following:

We had a public IP prefix advertised through our MPLS network.
This public prefix was propagated through ExpressRoute and traffic was working correctly.
The application was reachable without any issue.

As part of a Disaster Recovery test, we stopped advertising this public route from our MPLS environment. As expected, the public prefix disappeared from the ExpressRoute route advertisements.

From our VNet, both Internet-bound traffic and private traffic are routed to an Azure Firewall deployed in a vWAN hub.

However, after making this change, traffic started timing out.

What is interesting is that:

We can see the traffic arriving on the Azure Firewall in the logs.
The firewall rules appear to match correctly.
Despite this, the connections timeout and the communication does not complete.

My question is:

Is there any route convergence, propagation, or refresh delay within Azure Virtual WAN / Azure Firewall that should be considered when traffic transitions from a path using an ExpressRoute-advertised public prefix to a path using Azure Firewall Internet egress?

In other words, could there be a period during which Azure components still have stale routing information or asymmetric routing behavior after the public prefix is withdrawn from ExpressRoute advertisements?

Has anyone experienced a similar scenario or can provide guidance on troubleshooting this type of migration from ExpressRoute public routing to Azure Firewall Internet egress?

Thanks in advance.

Nassim Cherifi 75 Reputation points

2026-06-04T07:09:01.5966667+00:00

Hi,

Thank you for your detailed response.

I have already verified all the points you mentioned.

Everything appeared to be correctly configured and consistent with the expected design.

My main question is actually related to the expected convergence time in this scenario. Based on your explanation, this seems to be a routing convergence issue between ExpressRoute, Virtual WAN, and Azure Firewall after the route withdrawal.

Is there any documented or typical convergence timeframe for this process? In my case, I waited approximately 20 minutes after withdrawing the prefix, and the traffic was still not flowing through Azure Firewall as expected.

Should I expect convergence to take longer than 20 minutes in some cases, or would this indicate that another issue may be involved?

Thank you for your help.
Thanmayi Godithi 11,555 Reputation points Microsoft External Staff Moderator

2026-06-04T14:48:09.9633333+00:00

Nassim Cherifi , Thank you for the update and for confirming that the routing configuration, route tables, and firewall policies have already been validated.

Regarding your question on convergence time, Azure does not publish a specific convergence timeframe for route withdrawals across ExpressRoute, Virtual WAN, and Azure Firewall. However, route updates are typically reflected within a few minutes under normal conditions.

Given that you waited approximately 20 minutes after withdrawing the prefix, I would not generally expect routing convergence alone to be the cause of the continued timeout behavior. At that point, it would be worth investigating whether the traffic is successfully leaving Azure Firewall and whether the return path is functioning as expected.

As a next step, I would recommend reviewing the Azure Firewall logs to verify:

Whether the traffic is being allowed and forwarded by Azure Firewall.

Whether SNAT is being applied as expected for the outbound connections.

Whether corresponding return traffic is being observed by the firewall.

Whether there are any drops, resets, or asymmetric routing indicators in the logs.

Since you mentioned that the traffic is reaching Azure Firewall and matching the configured rules, the key point now is to determine whether the traffic is successfully egressing from the firewall and whether the response traffic is returning through the expected path.

If you need further assistance, please share the details requested over Private message.
Thanmayi Godithi 11,555 Reputation points Microsoft External Staff Moderator

2026-06-09T09:20:22.6033333+00:00

Hi @Nassim Cherifi ,

Just checking in to see if you have reviwed my previous message.

Let me know if you have any questions.Thank you

Answer accepted by question author

0 additional answers

Your answer

Nassim Cherifi 75 Reputation points

2026-06-04T07:09:01.5966667+00:00

Hi,

Thank you for your detailed response.

I have already verified all the points you mentioned.

Everything appeared to be correctly configured and consistent with the expected design.

My main question is actually related to the expected convergence time in this scenario. Based on your explanation, this seems to be a routing convergence issue between ExpressRoute, Virtual WAN, and Azure Firewall after the route withdrawal.

Is there any documented or typical convergence timeframe for this process? In my case, I waited approximately 20 minutes after withdrawing the prefix, and the traffic was still not flowing through Azure Firewall as expected.

Should I expect convergence to take longer than 20 minutes in some cases, or would this indicate that another issue may be involved?

Thank you for your help.
Thanmayi Godithi 11,555 Reputation points Microsoft External Staff Moderator

2026-06-04T14:48:09.9633333+00:00

Nassim Cherifi , Thank you for the update and for confirming that the routing configuration, route tables, and firewall policies have already been validated.

Regarding your question on convergence time, Azure does not publish a specific convergence timeframe for route withdrawals across ExpressRoute, Virtual WAN, and Azure Firewall. However, route updates are typically reflected within a few minutes under normal conditions.

Given that you waited approximately 20 minutes after withdrawing the prefix, I would not generally expect routing convergence alone to be the cause of the continued timeout behavior. At that point, it would be worth investigating whether the traffic is successfully leaving Azure Firewall and whether the return path is functioning as expected.

As a next step, I would recommend reviewing the Azure Firewall logs to verify:

Whether the traffic is being allowed and forwarded by Azure Firewall.

Whether SNAT is being applied as expected for the outbound connections.

Whether corresponding return traffic is being observed by the firewall.

Whether there are any drops, resets, or asymmetric routing indicators in the logs.

Since you mentioned that the traffic is reaching Azure Firewall and matching the configured rules, the key point now is to determine whether the traffic is successfully egressing from the firewall and whether the response traffic is returning through the expected path.

If you need further assistance, please share the details requested over Private message.
Thanmayi Godithi 11,555 Reputation points Microsoft External Staff Moderator

2026-06-09T09:20:22.6033333+00:00

Hi @Nassim Cherifi ,

Just checking in to see if you have reviwed my previous message.

Let me know if you have any questions.Thank you

Answer 1

Hi Nassim Cherifi ,

Thank you for reaching out on Microsoft Q&A forum.

When using Azure Virtual WAN (vWAN), it is recommended to leverage hub routing tables to control and direct traffic through the firewall. Features like routing intent can be particularly helpful for centralizing and simplifying traffic management.

Using User Defined Routes (UDRs) at the VNet level is generally not considered scalable or centralized, and therefore is not recommended in a vWAN architecture.

From the configuration reviewed, the Azure Firewall policy includes No SNAT (Network Address Translation) private IP ranges. Because of this configuration, traffic destined for these ranges is treated as private traffic, and the firewall will not SNAT or route it to the internet.

As a result, when the corresponding route is removed from ExpressRoute (ExR), there is no valid path for that traffic, leading to connectivity issues.

Recommendation

If the intention is for this IP address/range to be reachable over the internet, you should remove it from the “No SNAT” private IP ranges in the firewall policy. This will allow the firewall to treat it as public traffic and route it appropriately.