An administrator is troubleshooting a scenario where IPSec VPN tunnels between two FortiGates are flapping. The logs show Phase 1 is up but Phase 2 fails with 'no proposal chosen'. The remote FortiGate has multiple Phase 2 selectors configured. What is the most likely cause?
The error 'no proposal chosen' is often due to mismatched proxy IDs in Phase 2.
Why this answer
The 'no proposal chosen' error during Phase 2, despite Phase 1 being up, indicates a mismatch in the IPsec security association (SA) parameters. Since the remote FortiGate has multiple Phase 2 selectors configured, the most likely cause is that the local and remote proxy IDs (local and remote subnets) do not match any of the configured selectors. Phase 2 negotiation uses these proxy IDs to define which traffic should be encrypted; if they don't align, the IKE SA cannot be established.
Exam trap
The trap here is that candidates often confuse Phase 1 and Phase 2 failures, assuming any 'no proposal chosen' error is due to Phase 1 misconfigurations like PSK or certificates, when in fact Phase 1 is already up, isolating the issue to Phase 2 proxy ID mismatches.
How to eliminate wrong answers
Option B is wrong because mismatched pre-shared keys would cause Phase 1 to fail, not Phase 2; Phase 1 is already up in this scenario. Option C is wrong because aggressive Dead Peer Detection (DPD) settings can cause tunnels to flap (go up and down), but they do not produce a 'no proposal chosen' error; that error is specific to Phase 2 proposal mismatches. Option D is wrong because certificate validation failure would also prevent Phase 1 from completing, as certificates are used during IKE authentication in Phase 1, not Phase 2.