A site-to-site tunnel between HQ and branch Cisco Secure Firewall (FTD) devices comes up whenever HQ hosts send traffic first. When only branch hosts start traffic, the IKE SA forms but the IPsec SA is refused. What most likely explains this?
Select an answer to reveal the explanation.
Short Explanation
When a tunnel only works one way, think about how you describe the traffic, not the keys. If each side's idea of what to protect isn't a mirror image, one side happily accepts while the other side says no. Keys and DH groups break things in both directions, so they won't give you a one-way failure.
Full Explanation
Each peer proposes traffic selectors derived from its own protected network definitions when it initiates the child security association. If the definitions are not exact mirrors, for example HQ protects a narrower range than the branch proposes, the responder may accept a proposal that falls within its own definition but reject one that exceeds it. That produces a tunnel that forms when one side initiates and fails when the other does, with the IKE security association established in both cases. A preshared key mismatch fails authentication regardless of who initiates, and the stem states the IKE security association forms from the branch side, so authentication succeeds. Blocking UDP 500 from the branch would prevent the branch from establishing any IKE security association, yet the branch's IKE exchange succeeds. A Diffie-Hellman mismatch in the IKE policy prevents Phase 1 entirely in both directions, which contradicts the observed IKE success. Exam caveat: the same pattern appears when one side is configured with a dynamic or responder-only peer, so check both protected networks and peer roles when a tunnel is direction-dependent. Operational check: compare protected networks object by object on both peers, correct them to mirror exactly, then clear the security associations, generate traffic from the branch first, and confirm the IPsec security association forms.