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).
Anyway, I know I'm wordy but hopefully, the details here will help someone avoid or at least understand the pain.
I know the struggle that you are talking about. It has been a huge pain and actually forced me to create two organizations and transfer licenses between them. I've also had to have Tech Support remove the communications between hub sites as that poses another issue in itself.
You are right that third party VPNs are painfull. When I have somone that has a lot of these, or they are complicated in anyway I tent to put in a little baby Cisco ASA to terminate the VPNs on, and install the ASA next to the MX. This also gets me the bonus of being able to support AnyConnect.
@PhilipDAth: Yep, we've been considering the same. I've been [im]patiently waiting for recommendations from the SE team.
It's really too bad that all of the individual pieces of the MX's can't pull together. If we could just mix licenses and eliminate the co-termination nonsense, I'd be fine with keeping our clients in our Organization with their own Networks so that AutoVPN could be used. This way I could take advantage of our redundant MX100's and our redundant ISP feeds. This would be a dream scenario; perhaps I hope for too much.
Also, to refine your thoughts on third-party VPN's, even connecting MX6x's from the client sites are problematic since they have to be configured as Non-Meraki Peer VPN tunnels too. These suffer the same problems as the actual Non-Meraki firewalls.
Wait, you have multiple clients under the same org?! What is the use case for this?
For me, I have 4 orgs alone for my company in order to keep the traffic segregated. My main org is fairly large for devices and having a single coterm date for all those licenses makes budgeting a whole lot easier.
@Aaron_Wilson: the reason for having multiple clients under the same organization is so that we can make use of AutoVPN to overcome the inability to use hostnames in VPN configurations for our clients that have dynamic public IP's.