Site-Site VPN Design Flaws

RSCS
Conversationalist

Site-Site VPN Design Flaws

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).

 

  1. 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.
  2. 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.
  3. 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.

 

5 Replies 5
sLyDwAyZ
Here to help

@RSCS

 

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.

PhilipDAth
Kind of a big deal
Kind of a big deal

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.

RSCS
Conversationalist

@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.

Aaron_Wilson
A model citizen

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.

RSCS
Conversationalist

@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.

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels