Two FortiGates negotiate IKEv2 phase 1, but the tunnel never establishes. Diagnostics show phase 1 proposals do not match: one peer offers AES256-SHA256 with DH group 14, the other offers AES256-SHA256 with DH group 20. Both peers share the same pre-shared key and the same phase 2 selectors. What is the correct conclusion about why phase 1 fails?
- AThe pre-shared key mismatch is the real cause, because a differing DH group always indicates the authentication payload was computed with different secrets.
- BThe phase 2 selectors are too broad, so the kernel rejects the phase 1 SA before the Diffie-Hellman exchange can complete.
- CThe Diffie-Hellman group must match in at least one common phase 1 proposal, so groups 14 and 20 with no overlap cause the IKE SA negotiation to fail. Correct
- DIKEv2 ignores the Diffie-Hellman group during the initial exchange, so the failure must come from a mismatched encryption algorithm instead.
Why A is wrong: It is tempting to blame authentication when phase 1 fails, but the scenario states the keys are identical and a DH group is an independent negotiated parameter, so the key is not the fault here.
Why B is wrong: Phase 2 selectors are negotiated only after phase 1 succeeds and cannot block the phase 1 SA, so selector breadth cannot explain a failure that occurs during the phase 1 key exchange.
Why C is correct: Phase 1 builds the IKE SA using a mutually agreed Diffie-Hellman group; if neither peer offers a group the other accepts, the key exchange cannot complete and phase 1 fails even when encryption, hash, and the pre-shared key all match.
Why D is wrong: IKEv2 absolutely requires an agreed Diffie-Hellman group in the initial exchange, and the scenario shows encryption and hash already match, so blaming the cipher is both factually wrong and inconsistent with the diagnostics.