Phase 1 comes up cleanly between the NOC FortiGate and a substation peer, but phase 2 never establishes and no traffic passes across the tunnel. Which area should the engineer investigate first?
Select an answer to reveal the explanation.
Short Explanation
If phase 1 is already up, the peers have already proven they can authenticate and agree on the basics — so a pre-shared key or peer-IP problem is ruled out. A stalled phase 2 almost always means the data-plane proposal or the traffic selectors don't line up between the two sides.
Full Explanation
When phase 1 completes successfully but phase 2 never establishes, the problem is isolated to the phase 2 configuration itself, most commonly a mismatched encryption or authentication proposal for the IPsec SA, or selectors (source and destination subnets) on one side that don't correspond to what the other side expects — for instance, the NOC defining a wider subnet than the substation offers, so no combination satisfies both peers. The pre-shared key is exclusively a phase 1 authentication artifact; if it were wrong, phase 1 itself would never have completed, so a successful phase 1 rules that out as the cause of a later phase 2 failure. Similarly, the DH group is negotiated as part of phase 1 (and optionally re-used for PFS in phase 2, but a mismatch there would be a phase 2 proposal problem, not a phase 1 DH group problem specifically) — since phase 1 already succeeded, its DH group already matched. The remote gateway's public IP address is also a phase 1 concern used to locate and authenticate the peer; if it were misconfigured, the IKE exchange itself would fail to reach the peer at all, which contradicts the premise that phase 1 came up cleanly. The practical troubleshooting step is 'diagnose debug application ike -1' focused on quick-mode messages, cross-checking the phase 2 proposal list and selector configuration on both FortiGates side by side.