MX64 (spoke) VPN to Non-Meraki (SonicWALL) Hub

[DunJer622]

Greetings,

We're a SonicWALL shop that is looking to potentially move to Meraki.  I'm new to Meraki, so I am in the process of crash-course learning.  It is looking like we'll be swapping out our EOL TZ200 and TZ205 units with MX64 units.  That said, I'm in the early stages of R&D and PoC.  As we have an existing network, we're looking to gradually transition the implementation of the Meraki units.  So, onto my questions.  

Can I create a VPN with the MX64 to my SonicWALL NSA E5500 (network core router)?  The short answer is "yes", as I was able to use the Non-Meraki Peers section.  However, I had to setup the MX64 as the hub, as it would not let me assign it as a spoke (due to no hubs being identified in the organization).  Am I setting up this VPN correctly?  I'm concerned about adding the next MX64, as it will see the 1st MX64 as a hub.  Do I have to just keep setting up the MX64 units as hubs and then setup the non-Meraki Peer to the SonicWALL each time?  I could be doing 30+ locations this year.  Would it be more prudent to swap out the SonicWALL hub with an MX100 or MX400 first?  This would obviously interrupt my entire network greatly and lead to a repeat effort on the VPNs.  

With the VPN that I have created, I don't see how to setup failover for the actual VPN, should the SonicWALL hub's primary Internet fail.  With my SonicWALL endpoints, I can simply enter the primary and secondary IPs of the hub and the endpoints will automatically re-establish the VPN on the secondary IP, should the primary fail.  Can I do the same with Meraki?  Can I do it with an MX64 to a non-Meraki router (hub)?

I appreciate any assistance that anyone can provide.  I've scoured the online documentation without success.

Thank you,

Jeremy

[PhilipDAth · Accepted solution]

Yes, you need to configure them as hubs, and all hubs will form a VPN to all other hubs automatically.  You can't stop that.

Personally I would install a new MX hub "beside" your SonicWall hub.  Then migrate the sites across and then remove the SonicWall hub.  Much lower risk this way.

VPNs to non-Meraki devices do not support redundancy.    Meraki to Meraki VPNs (AutoVPN) support redundancy automatically without you needing to do anything special (unless you are going for a more complex layer 3 redundancy using OSPF or BGP).

[wbenton]

Regarding your comment: >>>all hubs will form a VPN to all other hubs automatically. You can't stop that.<<<

So you're saying that if I have 15,000 locations, that all 15,000 locations will automatically VPN to the other 14,999 locations?

[PhilipDAth]

No, because you wouldn't configure 15,000 locations as hub sites.

At that scale, you would probably have some core hubs, some regional hubs, and the rest would be spokes connecting to their regional hubs.

[wbenton]

>>>No, because you wouldn't configure 15,000 locations as hub sites.

At that scale, you would probably have some core hubs, some regional hubs, and the rest would be spokes connecting to their regional hubs.<<<

But if there are already 20 non-Meraki VPN Concentrators up and running in the data center which currently link up all 15,000 non-Meraki VPN locations. And you wanted to roll out Meraki MX65's over a 3 year period of time to all of those locations, the VPN Concentrators would still be a non-Meraki device and as such, you could not configure them as a Spoke because only Hubs can be selected with non-Meraki devices.

[PhilipDAth]

The verify first MX's to go in would be those 20 central units. Then you would start your roll out to the 15,000 locations.

[wbenton]

So all the central data center VPN Concentrators would also have to be replaced.

Isn't there a way to configure spokes with non-Meraki devices?

[PhilipDAth]

You wouldn't do it on a project this large. The complexity is not worth the risk.

[Dunky]

PhilipDAth Are you saying that this is possible?

I have a number of sites with an MX, all autonomous and with no requirement to talk to each other.

I do however need to create a VPN from each site to a non-Meraki peer (Azure).

At present every single site is configured as a hub which as a by-product means that I have a fully meshed network which I dont want.

How do I get each site to have a VPN to Azure without interconnecting sites (or splitting the organization in the dashboard).

Thanks in advance

[PhilipDAth]

You can't @Dunky.  You need to either use VPN firewall rules to prevent the sites from talking to each other or use a VMX in Azure and make only it the hub.

Even if you use a VMX as a hub, all the sites will still be able to talk to each other, they'll just route via the VMX in Azure, so you would still need VPN firewall rules.

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Firewall_Rule_Behavior 

[Mr_IT_Guy]

@DunJer622,

First off, welcome to the forums and Meraki in General!

One thing to keep in mind with the Security Appliances is the number of VPN tunnels that are connected to the device. The MX64/65 won't be able to handle as many tunnels as say an MX84 or above. Is there a central location that you will have all resources coming back to? Do you have a backup site? Do all your branches need to have direct connections to each other? Think about what you truly need in terms of your topology before you breakdown and buy a bigger MX device, but make sure you get a bit more than what you need. By this I mean that lets say you only are going to have 85 connections. I would spring for the MX100 (250 connections) vs the MX84 (100 connections). The reason for this... future growth. But that's just my $0.02

[DunJer622]

Thanks for the responses.  I've ordered another MX64 for Meraki-to-Meraki testing, with a parallel connection with my production network.  This is all PoC.  I'll then replace the "hub" MX64 with an MX100 or MX400, depending on my ultimate design and an understanding of 'connections'.  I was a little disappointed that the non-Meraki interaction wasn't better, but I guess it is to be expected.  I'm getting by in my testing for now, but will be glad to have the second unit.  The SonicWALL is making some of the testing tough, if not impossible.

Anyhow, again, thanks for the replies.

Jeremy