Site-To-Site VPN between MX and Firepower (managed by FMC)

Solved
JSalmond
Here to help

Site-To-Site VPN between MX and Firepower (managed by FMC)

Hi, after upgrading our Cisco Firepower Management Center and Cisco Firepower Threat Defence appliances to 7.0.1 we are having issues re-establishing out site-To-Site VPN and hoping someone can provide an insight in to the correct IPsec setting to use on both sides. 

 

Prior to the upgrade our MX used the IKEv1 default settings however 3DES and Diffie-Hellman groups 2 are unsupported on the FTD's.

 

Tried setting up IKEv2 with different combinations of setting but having trouble establishing a tunnel. 

 

MX running version  15.44 

1 Accepted Solution
KarstenI
Kind of a big deal
Kind of a big deal

You can use IKEv1 with AES, SHA1 or SHA256 and Group14. That works like a charm.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.

View solution in original post

8 Replies 8
KarstenI
Kind of a big deal
Kind of a big deal

You can use IKEv1 with AES, SHA1 or SHA256 and Group14. That works like a charm.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
JSalmond
Here to help

Thank you @KarstenI managed to to get the VPN re-established. 

AlexP
Meraki Employee
Meraki Employee

If IKEv1 is working and IKEv2 isn't, you may be running into traffic selector issues: https://documentation.meraki.com/MX/Site-to-site_VPN/IKEv1_and_IKEv2_for_non-Meraki_VPN_Peers_Compar...

PhilipDAth
Kind of a big deal
Kind of a big deal

When you use IKEv2 on MX you *must* specify the "remote id".  This is usually the IP address of the remote peer.

 

But seriously, whoever looks after your security - ask them to step back from the keyboard.  No one should have been using or deploying 3DES for a long time.  It has long been considered a deprecated protocol, and no person working in the security field would consider using it.

 

To get you back onto using accepted best practices, this is the NSA 2020 guide to IPSec VPN configurations.  Try and get something closer to these specifications.

https://media.defense.gov/2020/Jul/02/2002355501/-1/-1/0/CONFIGURING_IPSEC_VIRTUAL_PRIVATE_NETWORKS_... 

AlexP
Meraki Employee
Meraki Employee

If the remote ID field is left blank, we default to assuming the identifier of whom we're speaking to is their public IP - this should only be necessary in cases where the peer is behind a NAT and doesn't have that public IP specified as an identifier.

PhilipDAth
Kind of a big deal
Kind of a big deal

Are you sure @AlexP ?  I thought one of the 15.x releases made it mandatory.

AlexP
Meraki Employee
Meraki Employee

15.x included a change to a new IPsec daemon that enforces checks on it where previously our old one was bugged, and didn't. It's not mandatory that a value be populated on Dashboard if the default is what the peer presents when we key the IKE SA.

JSalmond
Here to help

@PhilipDAth @AlexP thank you both for helping and highlighting the documents relating to the issue we were experiencing and VPN best practices, much appreciated. 

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