Default IPSec configuration between Meraki peers

[NavyXC]

Looking to see if anyone knows what the default IPsec policies/key strengths, etc, are between Meraki peers.  I saw the whitepaper from 2013 that mentioned a proprietary algorithm/SSL to the cloud and then AES-128 for the IPSec tunnel, but was wondering if there was more detail anywhere on authentication, key exchange, etc, and how that's being done between Meraki devices.  Also, if Meraki was going to upgrade the IPSec tunnel to AES-256, IKEv2, other DH groups, etc? 

Good info for Meraki to non-Meraki but would like to know what is happening between all the Meraki devices for documentation to a third party as part of a review process.  Thanks!

[MerakiDave]

To some extent it can depend on MX firmware version.  Until maybe a year ago, the IPSec tunnels formed by AutoVPN used AES128 with CBC and HMAC-SHA1, the default SA timer is 28800 seconds (common requirement is no greater than 86400) and the default is DH Group 2 (1024-bit MODP).  In MX 13.x and newer firmware the default is SHA2.  And in a recent 14.x version there is now an option for HMAC-SHA256 authentication.  IKEv2 in the works.  Also coming is AES256 on AutoVPN, we actually do already support AES256 on 3rd party VPN, just not on AutoVPN yet but I think soon.  Any AutoVPN tunnel that gets built will use the highest possible policy set, crypto map and transform set that is mutually supported by both MX appliances.  If it happens to be a 3rd party VPN, you have the full range of choices 3DES or AES 128/192/256, SHA1/2, DH1/2/5, and a configurable SA lifetime.  You could probably open a Support ticket for your specific deployment to confirm the exact settings for your review process.

[Compliance_Guy]

Dave,

Can you clarify the SHA2 support for the Auto-VPN Functionality and 3rd Party VPN for MX13.x support and newer.  We need to validate this for a customer's NIST compliance.  Can you provide us any documentation on this?

Thanks!

[MerakiDave]

I'd give Support a ring to review that along with your specific requirements and confirm if anything is still in flux.  Might need to make a call on if something is available in beta firmware and if there's a likely timeline to GA.  Sorry not a concrete answer.

[fraya]

Is there any update as to whether IKE-v2 is now supported for AutoVPN? Also DH group 1/2/5 aren't secure anymore. Is DH Group 14 now supported?

[spadefist]

IKEv2 (along with AES256-CBC) can be configured for AutoVPN, just ask either support or your friendly Meraki CSE.  Also, the information about DH and AutoVPN above isn't correct (Dave you should have attended the MX session at SKO!).  As AutoVPN doesn't need/use DH as an MX-to-MX VPN connection has a shared management plane (dashboard), this means that mutual authentication and creating a secure connection (via DH) isn't needed per se.

This is mentioned in some detail in my latest blog post on the Meraki blog - https://meraki.cisco.com/blog/2018/06/all-about-autovpn/ and to a less extend in the original AutoVPN white paper.  Just remember that AutoVPN isn't full standard IPSec, its IPSec-like VPN, as there are some elements of the standard that it doesn't really make sense to burn the CPU clock cycles on when you're cloud managed.

Finally we investigating support higher DH groups e.g. 14 & 15 for non-Meraki VPN peers are its part of the NIST and NCSC standards for public sector entities.

HTH

Steve

[NavyXC]

Steve,

FWIW I had one of my guys ask support today (as you suggested) - see below - and here's what he got back.  We have over 100 sites meshed together using AutoVPN and the technology works great - no issues there.

Don't know what the right answer is...

Ken

[spadefist]

Thanks for replying Ken, I have reached out to Priyank to correct him, as I assure you that IKEv2 is supported!  However, in your case I see you have a sizeable Z1 estate.  That's important as the Z1 doesn't currently support IKEv2, so it's not something you can implement as you have Z1's in your AutoVPN domain.

Cheers

Steve

[NavyXC]

Thanks for the update.  That's an important distinction...

Is it a hardware or firmware issue with the Z1s?  And is everything from the Z3 up capable?

I'm assuming you can only go as high as your weakest link in the overall network (of networks)...correct?

[spadefist]

It's fair to say it's a hardware thing, as the CPU in the Z1 has much less capacity than the rest of the line (Z3 and up), we have seen Z1's working with IKEv2, however we are not comfortable dedicating the amount of CPU time to the IKEv2 process that that would require.  Hence, we took the decision to exclude Z1's from IKEv2.

With respect to you 'weakest link' question, that's a good analogy, but it's also worth standardising on a homogeneous technology set across your organisation (i.e. all or nothing) for both simplicity and diagnostic reasons.

[NavyXC]

Thanks - really appreciate the detail and responses.

We have standardized on a homogeneous technology in Meraki - across the board. 

What I didn't have an appreciation for until now was the deprecation (or lack of inclusion) of this type of capability as the products evolve given everything is still relatively new.  The Z1s/Z3s serve a specific purpose as much as our MX400s and they all need to work together.

[Sudha]

HI

I like to know is there any lifetime for pre-shared key used for non-Meraki VPN , as we have VPN with third party which is keep on expiring after some days and we are configuring again and again 

MX version is 14.40 and IPsec policy - default 

[spadefist]

The key material used for non-Meraki VPN is used until it is manually changed if you are seeing a need to change it this I presume would be dictated by the device/org you are peering with.