Between two Cisco Secure Firewall (FTD) peers, the IKEv2 security association is established and authenticated, but no IPsec (child) security association ever forms. Which cause best fits this symptom?
Select an answer to reveal the explanation.
Short Explanation
Think of Phase 1 as building the secure phone line and Phase 2 as agreeing on what you'll actually talk about. If Phase 1 is up, the keys and reachability already worked. So you look at Phase 2 ingredients: matching protected networks and a shared IPsec proposal.
Full Explanation
An established and authenticated IKE security association proves that the peers reached each other on the IKE ports, agreed on IKE algorithms, and verified credentials. The child security association is negotiated next and depends on two further agreements: the IPsec proposal, meaning encryption and integrity for user traffic, and the traffic selectors derived from the protected networks, which must correspond as mirror images on the two peers. A mismatch in either causes the child security association to be refused while the IKE security association remains up, exactly matching the symptom. A preshared key mismatch fails authentication, so the IKE security association would never be authenticated. Blocking UDP 500 prevents the initial exchange entirely, so no IKE security association would exist. An access control rule that blocks decrypted traffic acts on packets after the tunnel exists; it does not prevent child security associations from being negotiated, so it explains traffic loss, not a missing security association. Exam caveat: some platforms narrow traffic selectors when one side is a subset of the other, so partial mismatches can produce intermittent or one-directional behavior. Operational check: compare protected networks and IPsec proposals on both peers, look in the VPN logs for a traffic selector or proposal rejection, correct the configuration, and confirm that IPsec security associations now appear for the protected network pair.