We've had our Meraki gear for almost a year now and, while helpdesk, SE's and account reps have all been as helpful and pleasant to work with as one could hope, the underlying design of the Site-Site VPN is problematic. I have about 20 years in I.T. and have never encountered VPN solutions with these kinds of design weaknesses. Someone really didn't think things through.
We have a datacentre with several clients that connect via site-site VPN using a variety of client-side firewalls. WatchGuard, Sonicwall, Cisco, and Meraki. On our end, we have a pair of MX100's. We had MX84's which exhibited the same behaviour as below but had other issues resulting in their replacement (known issue causing broadcast storms which, combined with MS120's that had a known issue that they didn't properly deal with broadcast storms, resulted in complete stack failure resolved only by manual power cycling).
- Any configuration change that even thinks about being related to Site-Site VPN causes ALL site-site tunnels to reset. Only the affected tunnel should be reset.
- need to add a site-site firewall rule for one client, all connections are reset.
- Need to add a new site-site connection, all connections are reset.
- Need to change an existing site-site VPN connection, all connections are reset.
- Add/change/remove a VLAN, all connections are reset.
- No ability to disable/re-enable a VPN tunnel.
- We frequently get calls from clients stating that their tunnel suddenly refuses to pass traffic. The tunnel shows up on both ends but no traffic will pass. The fix is to disable/re-enable the tunnel but you can't do that from the Meraki portal. It's a simple task from pretty much every other device so we normally do this from the client's device. Great but what if you don't have access to the client's device? You have to make a configuration change on our end and reverse that change to cause the tunnel to reset.
- Of course, this leads us back to #1 where this causes all tunnels to reset. We've had instances where we fix one tunnel only to have to fix another that failed during the reset.
- This is a layered issue so buckle in. No ability to use hostname's for client-side firewalls.
- Some of our clients have dynamic IP addresses. I know they could/should pay for a static one but we were successfully using Dynamic DNS services to provide hostnames used in our VPN configurations before switching to Meraki.
- Another solution would be to ensure that they have a Meraki on their end and then we can use AutoVPN right? Not exactly.
- In order to use AutoVPN, the MX's must be in the same Organization. The first problem with this is with licensing termination dates. All devices in an Organization adopt the same license termination date so if our client buys a device this year with a three-year license but our license renews next year, their device will also stop working next year. Basically, you have to start tracking licenses manually. My understanding is that this is something they are working on.
- There's a second hitch here. Our MX's have Advanced licensing but our client's license is an Enterprise license. All device types in an Organization must have the same level license. We can either ensure that all clients have Advanced licenses or we have to downgrade our license to Enterprise. There is no way around this. We're still trying to figure out how to get this accomplished since the licenses are already in place.
Anyway, I know I'm wordy but hopefully, the details here will help someone avoid or at least understand the pain.
