A new site-to-site tunnel between two Cisco Secure Firewall (FTD) devices never completes IKEv2 Phase 1. The logs show each peer rejecting the other's IKE_SA_INIT proposal because no acceptable proposal was found. What is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
Phase 1 is a handshake where both sides have to pick the same language from a menu. If you don't share a single combination of cipher, integrity and DH group, nobody can agree and the conversation never starts. Don't get distracted by Phase 2 stuff like proposals and protected networks; they don't even come up until Phase 1 is done.
Full Explanation
In IKEv2, the first exchange, IKE_SA_INIT, negotiates the cryptographic suite for the IKE security association: encryption, integrity, pseudo-random function and Diffie-Hellman group. Each peer offers the policies it has configured, and if no combination is common to both, negotiation fails with a no-proposal-chosen type error before authentication even begins. Aligning the IKE policies, or adding a shared policy, resolves the failure. IPsec proposals govern the child security association that protects user traffic; they are negotiated later, in IKE_AUTH, so a mismatch there produces a Phase 2 failure after Phase 1 completes. Non-mirrored protected networks also affect the child security association, through traffic selectors, and likewise surface only after the IKE security association exists. A missing NAT exemption changes how user traffic is translated and can stop traffic from matching the VPN, but it does not cause the peers to reject each other's IKE_SA_INIT proposals. Exam caveat: a preshared key or certificate problem fails Phase 1 too, but it appears during authentication, not as a proposal mismatch. Operational check: compare the IKE policies on both devices, ensure at least one identical policy exists, redeploy, and confirm with the IKEv2 security association display that the tunnel is established with the expected algorithms.