Non-Meraki VPN peer + Meraki autoVPN - routing

[Arnout]

Hi! 

At our company we are using MX appliances for the HQ and the braches. The branches are divided in two business units. Business unit 50 and 3 with there own unique private subnets. The branches are the SPOKE's and at the HQ the MX is set-up as HUB.

Now! For an external web services application i need to setup a IPSEC Site-2-Site with Non-Meraki VPN peer. This web services application is only needed for users at the HQ and business unit 50 (about 30 spokes).

I managed to build the IPSEC to the HQ MX HUB, and i am able to ping the Non-Meraki VPN subnet, but i am unable to reach the Non-Meraki VPN at the spokes. Its just not routing the IPsec VPN traffic. I have attached a diagram of our setup.  Could you please help to find a solution for this. 

Thank in advance.

Arnout

[PhilipDAth]

You can't do that.  You will also need to build the non-Meraki VPN to each spoke.

You may find it easier to buy an additional MX and host it where ever the web services application is (if they will allow it).

[Ahmed_Fathy]

Dear Philip

Is the above solution still the only valid one or there is any better workaround without extra MX appliance? 

[PhilipDAth]

>Is the above solution still the only valid one

Correct.

[Seyidoff]

Hello,if my network is like this what settings should i do on my newly installed meraki device?

[PhilipDAth]

Are you able to install your new MX at the cloud provider?

[Seyidoff]

I have opened a new dashboard and it is installed.

[PhilipDAth]

Another solution is to buy an additional MX to go at the hub site, but place it in a different organisation.  This should go on the same LAN as your existing hub MX.

On the new MX add a static route pointing to your AutoVPN MX that covers all of your subnets.  On your AutoVPN MX add a static route pointing to the remote site to site VPN destination with the new MX as the next hop, and publish this static route into AutoVPN.

Then build the site to site VPN to the new MX.

Voila.  All your spokes now have access.

[Arnout]

Hi Philip, 

Thanks for your response and help :).

I think the solution with the additional MX sounds the best and easiest way.

But one question, why should this MX run in a different organisation? 

[PhilipDAth]

>But one question, why should this MX run in a different organisation? 

You are going to have to make the new MX an AutoVPN hub (it wont have any spokes) to enable the non-Meraki site to site VPN.  You wont be able to add a static route pointing to the AutoVPN spokes via the other proper hub.  It wont allow it to be added.

Actually, if you get the supernetting correct it may be possible, but it would be safer to put it into another organisation.

Actually, this article by Aaron Willette explains it really well.

http://www.willette.works/merging-meraki-vpns/

[gavins1040]

Hi, 

I'm currently setting the below up with a new MX. Just to check should the Non Meraki VPN MX have a separate public IP address from the Meraki AutoVPN MX?

[PhilipDAth]

If they are two seperate MX units then yes, they should each have their own public WAN IP address.

[Toby]

Bear with me but shouldn't this work without using a separate MX?

Since the spokes have a default route back to the hub and the hub have the routes to the non Meraki VPN networks, shouldn't the spoke traffic have reachability to the non Meraki VPN networks?

[StarBlink]

I currently have this situation, does MX 18.107.2 still have this Meraki VPN - Non Meraki VPN routing limitation?

[PhilipDAth]

Yes.  That won't be changing.