S2S VPN not propagating route to spoke and hub vnet

aferland 1

I have a hub and spoke topology and one of my spoke hosts a VPN Gateway that has a S2S VPN with another VNET (in another tenant).

The IP Range of the remote network (10.10.6.0/24) (connected with S2S VPN) is not added in my route table (and therefore in the BGP table).

What am I missing here? What configuration do I have to do to have this IP range propagated in my route table and BGP table?

2 answers

Joe Carlyle 661 Reputation points MVP

2022-11-24T09:40:41.07+00:00

Your current architecture won't work I am afraid. There is no capability to write those transient hops into system route tables.

You could make it work, if you change your 10.6 spoke to terminate in your hub VNG rather than on a spoke, which would be best practice and give you central routing.

There is no other architecture that will write routes over BGP as you require.
Please sign in to rate this answer.

1 person found this answer helpful.
aferland 1 Reputation point

2022-11-24T14:13:07.577+00:00

Thank you for your feedback.

Let's say I add my S2S connection on my current ExpressRoute GW as you suggest, according to the doc, if I want transit between my ExpressRoute and S2S VPN, I would need to add a (costly) Azure Route Server. (See here : https://learn.microsoft.com/en-us/azure/expressroute/expressroute-howto-coexist-resource-manager#to-enable-transit-routing-between-expressroute-and-azure-vpn)

Do you confirm or am I reading it wrong?

Thanks
Sign in to comment
Bas Pruijn 946 Reputation points

2022-11-24T13:23:24.823+00:00

In theory you might be able to add a user defined route to the 10.10.4.0/24 network defining the next hop for the 10.10.6.0/24 network to be the IP address of the VPN Gateway in the 10.10.5.0/24 network. Whether this would then automatically be propagated over BGP to the LAN network, I do not know (but I sincerely doubt that). You night need to add extra custom routes to your LAN network to make this work.

you could start with adding this UDR and then test from the VM in the 10.10.4.0/24 network and see if that VM can connect. I bet that in your current set-up this VM also cannot connect to the 10.10.6.0/24 network. You first need to fix that step. Then you can look into propagating that communication to the LAN network.

I do agree with @Joe Carlyle that your set-up is not according to best practices.
Please sign in to rate this answer.
aferland 1 Reputation point

2022-11-24T14:14:15.973+00:00

Thank you for your feedback. I'd rather stick to best practice even if what you are proposing "might" work.

Bas Pruijn 946 Reputation points

2022-11-24T16:24:51.883+00:00

I really think the best practice would be to create a VNET peering between your 10.10.4.0/24 HUB network and your 10.10.6.0/24 spoke network. This would imply you do not need any VPN to be set up. I am curious on why you would insist on using VPN for this connection. Please see also https://azure.microsoft.com/en-us/blog/vnet-peering-and-vpn-gateways/

You mention that route server is very expensive, but compared to Express route and Azure Firewall I think the price is not excessive. Route server is a (relatively) new product that helps you to automate the routing (what's in the name ;) ). If you do not want to spend the money on that, you could use User Defined Routes to achieve a working situation.

aferland 1 Reputation point

2022-11-24T16:37:36.217+00:00

The VNET I am trying to connect to (10.10.6.0/24) is in another tenant.

You are correct, I could use a simple cross-tenant VNET peering also. I'll look into it.

As for the Azure Route Server, you mean that I could instead use UDR to enable traffic flow between ExpressRoute and the S2S connection with just a manual route on my Gateway subnet route table and I would get the same result? It doesn't seem to be suggested in the documentation.

Bas Pruijn 946 Reputation points

2022-12-01T15:22:35.227+00:00

I personally would stay away from UDR if possible. I do think that maintenance and transparency is difficult.

On this page: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined it states that you can define a UDR that uses the VPN Virtual Network Gateway as a next hop for certain address ranges.

You should be able to define a UDR on the 10.10.4.0/24 network that defines the next hop for the 10.10.6.0/24 network to be the VPN Gateway in the 10.10.5.0/24 network. I do doubt a bit that these UDR's will be propagated via BGP to on premises though.
Sign in to comment