Part of routes learned by Azure VPN Gateway is not propagated to its VNET

Question

Part of routes learned by Azure VPN Gateway is not propagated to its VNET

Cat Mucius 91

Good day,

We have a very curious and non-standard situation.

We have a VPN Gateway connected to number of BGP-over-IPsec peers. It learns routes from them by BGP and propagates (injects) them into its VNET (as well as to a number of spoke VNETs, all having the "Enable <spoke-VNET> to use remote gateway or route server" flag set).

All works as planned, except one thing - routes learned from particular peer (a Virtual WAN of another tenant) are NOT propagated to the Gateway-hosting VNET or to spoke VNETs peered with it.

I should emphasize that:

The routes from the Virtual WAN ARE learned by the VPN Gateway - it's not a issue of non-working site-to-site VPN. It even successfully re-advertises them to its other peers.
It's NOT a problem of a Route Table (UDR) blocking propagation - I was checking "Effective routes" for VMs attached to subnets without UDRs or with UDRs having the propagation enabled. Besides, routes from all other BGP peers appear there. Only routes from the Virtual WAN do not.
If I configure static route towards the Virtual WAN on the "Local Network Gateways" representing it - the route IS successfully propagated to the VNETs.
Apparently, it's also NOT a problem with max limits: I've disconnected some BGP peers temporarily from the VPN Gateway to see whether the Virtual WAN routes will be injected instead of theirs - and no, this DIDN'T happen.
I've tried resetting the VPN connections, the VPN Gateway itself and the gateway on the Virtual WAN side - this didn't make any difference.

What can cause these specific routes not to arrive to the SDN level?

ISHARA LAKSHAN 0 Reputation points

2025-03-01T14:41:23.93+00:00
It sounds like you've already done a thorough check, but here are some ideas to troubleshoot the issue further:

Check the Virtual WAN Configuration: Even though you're learning routes from the Virtual WAN, it might not be set up to properly advertise them to your VPN Gateway. There could be specific settings on the Virtual WAN side that are limiting or filtering route propagation.

Review BGP Filters: Double-check if there are any BGP filters or route maps configured on your VPN Gateway or on the Virtual WAN that might be preventing certain routes from being propagated. Sometimes, BGP can filter routes based on attributes, even if they're learned.

Ensure Proper Propagation Settings: You mentioned that routes from other peers are showing up, but not the ones from the Virtual WAN. It could be that the propagation settings aren’t fully enabled for routes coming from that specific peer. Make sure the route propagation for that particular BGP session is fully enabled for your VNETs and spoke VNETs.

Check for Route Conflicts: Since static routes towards the Virtual WAN are propagating but the BGP-learned ones aren’t, there could be a route precedence issue. If static routes are set with higher priority, they may override the dynamic BGP-learned routes, preventing those from propagating.

Log Insights: It might be worth reviewing BGP logs for any errors or warnings when the routes are being learned from the Virtual WAN. Sometimes, issues like misconfigured BGP sessions or misalignment of BGP attributes can block propagation.

Azure Limits and Quotas: You already tested with disconnecting other peers, but it’s still possible that you're hitting some internal limits on your VPN Gateway, preventing it from injecting new BGP routes. Check if there are any max route limits you're hitting in the Azure documentation.

If all else fails, reaching out to Azure support could be a good option—they can look deeper into the configuration and provide more targeted help.
Cat Mucius 91 Reputation points

2025-03-03T15:41:52.1966667+00:00
It would be nice if Microsoft would:

Document that VPN Gateway used in conjunction with ExpressRoute Gateway cannot be peered with any Virtual WAN (at least if BGP is used for this peering).

Allow changing ASN either for ExpressRoute Gateway, for Virtual WAN or for both.

2 answers

Your answer

Cat Mucius 91 Reputation points

2025-03-03T15:41:52.1966667+00:00

It would be nice if Microsoft would:

Document that VPN Gateway used in conjunction with ExpressRoute Gateway cannot be peered with any Virtual WAN (at least if BGP is used for this peering).

Allow changing ASN either for ExpressRoute Gateway, for Virtual WAN or for both.

Answer 1

Microsoft support have discovered the reason.

Besides being peered with a number of regular BGP-over-IPsec peers, the same VPN Gateway of mine was also used to establish BGP-over-IPsec-over-ExpressRoute connections with on-premises routers, a setup described in the "Configure a Site-to-Site VPN connection over ExpressRoute private peering" article.

Such setup requires ExpressRoute Gateway to be deployed in the same GatewaySubnet of the same VNET as the VPN Gateway. The ExpressRoute Gateway comes with non-modifiable ASN 65515 and its instances establish BGP peerings with instances of the VPN Gateway.

But Virtual WAN also comes with the same ASN 65515, which also cannot be changed. So a conflict arose, which prevented (not exactly clear why) the routes learned by the VPN Gateway to be propagated to the VNETs using it.

As soon as I removed the ExpressRoute Gateway, the problem disappeared. (Just disconnecting it from the ExpressRoute circuit wasn't enough, as it still continued to advertise its own addresses with ASN 65515).

As a workaround, I simply set up the ExpressRoute connectivity via the Virtual WAN - deployed an ExpressRoute Gateway, connected it to my circuit (the Authorizations mechanism allows easily doing so across tenants) and established IPsec tunnels over it to the site-to-site VPN Gateway of the same WAN Hub. No ASN conflict arises in this case.

The architecture is outlined at "ExpressRoute encryption: IPsec over ExpressRoute for Virtual WAN".

Answer 2

Hello Cat Mucius

Greetings!

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I'll repost your solution.

Please click "Accept" the answer as original posters help the community find answers faster by identifying the correct answer.

Issue: Part of routes learned by Azure VPN Gateway is not propagated to its VNET

Resolution:

Besides being peered with a number of regular BGP-over-IPsec peers, the same VPN Gateway of mine was also used to establish BGP-over-IPsec-over-ExpressRoute connections with on-premises routers, a setup described in the "Configure a Site-to-Site VPN connection over ExpressRoute private peering" article.

Such setup requires ExpressRoute Gateway to be deployed in the same GatewaySubnet of the same VNET as the VPN Gateway. The ExpressRoute Gateway comes with non-modifiable ASN 65515 and its instances establish BGP peerings with instances of the VPN Gateway.

But Virtual WAN also comes with the same ASN 65515, which also cannot be changed. So a conflict arose, which prevented (not exactly clear why) the routes learned by the VPN Gateway to be propagated to the VNETs using it.

As soon as I removed the ExpressRoute Gateway, the problem disappeared. (Just disconnecting it from the ExpressRoute circuit wasn't enough, as it still continued to advertise its own addresses with ASN 65515).

As a workaround, I simply set up the ExpressRoute connectivity via the Virtual WAN - deployed an ExpressRoute Gateway, connected it to my circuit (the Authorizations mechanism allows easily doing so across tenants) and established IPsec tunnels over it to the site-to-site VPN Gateway of the same WAN Hub. No ASN conflict arises in this case.

The architecture is outlined at "ExpressRoute encryption: IPsec over ExpressRoute for Virtual WAN".

Document that VPN Gateway used in conjunction with ExpressRoute Gateway cannot be peered with any Virtual WAN (at least if BGP is used for this peering).
Allow changing ASN either for ExpressRoute Gateway, for Virtual WAN or for both.

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Praveen Bandaru 850 Reputation points Microsoft External Staff

2025-03-04T11:43:45.3466667+00:00

Hello Cat Mucius

Greetings!

Following up to see if the above answer was helpful. Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Praveen Bandaru 850 Reputation points Microsoft External Staff

2025-03-05T12:17:07.5366667+00:00

Hello Cat Mucius

Greetings!

Following up to see if the above answer was helpful. Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Share via

Part of routes learned by Azure VPN Gateway is not propagated to its VNET

2 answers

Your answer