Why Is IPsec Phase 1 Up but Phase 2 Down?
A FortiGate is configured with an IPsec VPN to a remote site using IKEv1. The VPN tunnel goes down intermittently. The admin runs 'diagnose vpn ike gateway list' and sees 'state=UP' but no Phase2 selectors. What is the most likely cause?
⚠ Common exam trap
Test-takers frequently assume a UP gateway state means the entire VPN tunnel is working, but in IKEv1, Phase1 can be UP while Phase2 is down, leading to intermittent connectivity; the key is to check Phase2 selectors separately.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Mismatched Phase2 parameters between the local and remote gateways
When 'diagnose vpn ike gateway list' shows the IKE gateway state as UP but no Phase2 selectors are present, it indicates that the IKE Phase1 (main mode or aggressive mode) has completed successfully, but the IPsec Phase2 (quick mode) negotiation has failed. The most common cause for this is a mismatch in Phase2 parameters such as encryption algorithm, authentication algorithm, or proxy IDs (local/remote subnets) between the local and remote gateways. Since the tunnel goes down intermittently, the Phase2 rekey may be failing due to these mismatches, causing the tunnel to drop until a successful renegotiation occurs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The firewall policy allowing IPsec traffic is misconfigured
Why it's wrong here
A misconfigured firewall policy would not prevent Phase2 establishment because policies are evaluated after the tunnel has been negotiated. Phase2 (Quick Mode in IKEv1) is an IKE control-plane exchange that matches IPsec security association proposals between the two gateways. Firewall policies govern traffic flow through the established tunnel, and a policy issue would result in dropped or blocked data traffic, not a failure to establish the Phase2 SA. Thus, while policies are important for permitting user traffic, they are irrelevant to Phase2 formation.
- ✗
The remote gateway has a different PSK
Why it's wrong here
A mismatched pre-shared key (PSK) would trigger a Phase1 failure during the Main Mode or Aggressive Mode authentication exchange. The PSK is used to derive authentication material for the IKE SA, and if it differs between peers, the authentication payload fails and the IKE SA never becomes active. Since Phase2 relies on an existing Phase1 SA to negotiate the IPsec SA, a PSK mismatch prevents the tunnel from ever reaching Phase2. Therefore, the Phase2 failure described in the question cannot be attributed to a PSK discrepancy.
- ✓
Mismatched Phase2 parameters between the local and remote gateways
Why this is correct
Phase2 negotiation, also known as Quick Mode in IKEv1, is dedicated to agreeing on IPsec SA parameters such as encryption algorithm, integrity algorithm, DH group, PFS, and SA lifetimes. If the local FortiGate proposes a set of algorithms that do not overlap with the remote gateway's configured Phase2 proposal, the negotiation ends in a NO_PROPOSAL_CHOSEN error and no IPsec SA is created. The tunnel may appear to be up (Phase1 complete) but never passes traffic because Phase2 is stuck or continuously re-negotiating. Matching every parameter, including subtle settings like PFS and key lifetime, is mandatory for successful Phase2 establishment.
- ✗
Dead Peer Detection (DPD) is disabled
Why it's wrong here
Dead Peer Detection (DPD) is an IKE mechanism used to monitor the liveness of the remote gateway after the IPsec SA has already been established. DPD sends periodic R-U-THERE messages and removes stale SAs if no response is received, but it does not influence the initial Phase2 negotiation. Disabling DPD means the FortiGate will not proactively detect a dead peer, which could leave stale tunnels, but it has no bearing on whether the Phase2 SA can be established in the first place. Thus, DPD status is unrelated to a Phase2 establishment failure.
Visual reference
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
Go deeper
Related to this question
About these practice questions
One of 773 original NSE4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.