Accessing Azure via Meriki MX client VPN

[JimC1]

Hello,

A client has a site to site VPN using two Meraki MX devices. Each MX device also has a non-Meraki VPN peer set up to connect to the Azure subnet. When onsite at either location everything is accessible. Both office locations (172.20.20.x, 172.20.40.x) and Azure (172.20.60.x) are fully accessible. 

When connecting via the Client VPN (10.253.1.0/24) to the main office, both offices are accessible but we cannot reach the Azure subnet. What the best option here? Some static routing? I'm a sys-admin and don't usually get deeply involved in routing. 🙂 

Thank you!  

[Brash]

I've never had to do this myself, but my understanding is that you can advertise the client VPN subnet to the non-meraki VPN peer just like any other local subnet.

Solved: non-meraki vpn, include client vpn - The Meraki Community

[JimC1]

I did enable this setting today. It did help somewhat. Before this when you VPN in you could only access the main office. Now you can access both offices but there isn't much of anything in the other office anyone would want to access remote. Still can't get to Azure though unless I'm on premise. 

[MartinLL]

Did you add the Client VPN subnet to a routing table in Azure?

I dont know how your vPC is set up, but if you dont run any dynamic routing you need to attach a Route Table to your subnets that tells azure that if you want to reach 10.253.1.0/24 you need to go to next hop Virtual appliance with your vMX private IP as the destination.

[JimC1]

Oh no, I didn't. Sounds like this might be the other part I'm missing along with what Brash mentioned above. So I have a VM subnet and a gateway subnet in Azure. Do I add this route to both? And the xMX private IP is the gateway address 172.20.20.1? 

Thanks in advance! 

[MartinLL · Accepted solution]

Sorry i read wrong in your original post and tought you had a vMX. Since you are using the Azure VN Gateway that changes things a bit.

Firstly you would need to check that the client subnet 10.253.1.0/24 is added to the (i assume) VPN tunnel from the main office to the Azure Gateway.

Secondly, you would need to check if 10.253.1.0/24 is added to your local network gateway for the main office VPN tunnel in Azure.

https://learn.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal 

When an address range is added to the local network gateway with an active VPN tunnel that network gets adverticed in your Azure VNETs.

You might need to do some static routing on your main office VPN device as well depending on what sort of device it is.

[JimC1]

Awesome, that worked! I added 10.253.1.0/24 to the address space for the local network gateway and it woke right up! I accepted this as the answer but Brash gets partial credit too. Thanks both of you!