Just like “crypto isakmp policy”, the “crypto ikev2 policy” configuration is global and cannot be specified on a per-peer basis. If there’s a mismatch, “debug crypto ikev2 error” will show something like this:
IKEv2-ERROR:(SESSION ID = 685,SA ID = 1):Expected Policies: : Failed to find a matching policyProposal 1: AES-CBC-128 SHA256 SHA256 DH_GROUP_2048_MODP/Group 14
There are two solutions. The simplest is specify all possible encryption, integrity, and PFS parameters in a single proposal:
crypto ikev2 proposal MY_IKEV2_PROPOSAL encryption aes-cbc-256 aes-cbc-192 aes-cbc-128 3des integrity sha512 sha384 sha256 sha1 group 14 5 2 crypto ikev2 policy MY_IKEV2_POLICY proposal MY_IKEV2_PROPOSAL
Alternately, write separate proposals, then list them in the policy by preference:
crypto ikev2 proposal HIGH encryption aes-cbc-256 aes-cbc-192 aes-cbc-128 integrity sha512 sha384 sha256 group 16 14 crypto ikev2 proposal MEDIUM encryption aes-cbc-256 aes-cbc-192 aes-cbc-128 integrity sha256 sha1 group 14 5 crypto ikev2 proposal LOW encryption aes-cbc-128 3des integrity sha1 md5 group 2 crypto ikev2 policy MY_IKEV2_POLICY proposal HIGH proposal MEDIUM proposal LOW
I am disappointed Cisco did not design things so policies could be associated with individual peers. Imagine a router terminating VPNs to different business partners, where Partner A insists on AES256/SHA512/Group16, while Partner B is still doing 3DES/MD5/Group2. You would write the policy with the most secure at the top, but there’s nothing to stop partner A from downgrading to partner B’s policy. It’s a security concern, plus takes extra time to negotiate.
Palo Alto Firewalls supports different ISAKMP policies on a per-IKE gateway basis and it’s one of the reasons I’ve really preferred them for Site-to-Site VPNs over the years.
