As shown in the figure, FW_A establishes an IPSec tunnel with FW_B, and executes the display ike sa command on FW_A. The following information is obtained: < FW A > display ike sa Current ike sa…

Question

Exhibit

Options

• AThe route to the IKE peer is unreachable
• BThe ACLs at both ends do not overlap.
• CThe "remote gateway" of the local end does not match the "local address" of the opposite end.
• DInconsistent encryption algorithms

• A
  17% (11)
• B
  71% (46)
• C
  3% (2)
• D
  9% (6)

Explanation

Option B is correct because ACL mismatch between the two firewalls affects IPSec Phase 2 (traffic selector negotiation), not IKE Phase 1 (SA establishment). Since the output shows ike sa number: 0, Phase 1 never completed - and ACL non-overlap cannot cause Phase 1 to fail, only Phase 2.

The other three options all directly prevent IKE Phase 1 from completing: A (unreachable route) means IKE UDP packets never reach the peer; C (remote gateway / local address mismatch) means the IKE peers are trying to talk to the wrong endpoints, so they never handshake; D (mismatched encryption algorithms) causes the Phase 1 proposal exchange to fail since both sides must agree on cipher, hash, DH group, and lifetime.

Memory tip: Think of IKE Phase 1 as "Can we talk?" and Phase 2 as "What traffic do we protect?" - a zero IKE SA count means the peers never even started talking, so ACL rules (which govern what to protect in Phase 2) are irrelevant to the failure.

No community discussion yet for this question.