NSE7 Advanced VPN and Zero Trust Practice Question
A network administrator is troubleshooting an IPsec VPN tunnel between Site A (FortiGate) and Site B (third-party VPN peer). The tunnel fails to establish. On FortiGate, phase1 status shows 'up' but phase2 status remains 'down'. What is the MOST likely cause?
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
✓
The phase2 proposal (encryption, authentication, etc.) does not match.
Phase1 being up indicates IKE SA is established. Phase2 down indicates IPsec SA negotiation failed, typically due to mismatched proposals (encryption, integrity, PFS) or traffic selector mismatch.
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 phase2 proposal (encryption, authentication, etc.) does not match.
Why this is correct
A phase1 'up' but phase2 'down' means IKE SA negotiation succeeded, so the mismatch lies in the phase2 proposal parameters. FortiGate's phase2 selectors, encryption, authentication, and PFS settings must match the third-party peer exactly; any difference in these attributes prevents the IPsec SA from establishing.
- ✗
The firewall policies at Site B are blocking UDP port 500.
Why it's wrong here
Blocking UDP 500 would prevent IKE negotiation entirely, so phase1 could not reach 'up' — the stem already rules this out. It is tempting because UDP 500 carries IKE, and a blocked port is a classic tunnel failure; that would be the answer if phase1 itself stayed down.
- ✗
The pre-shared key does not match on both sides.
Why it's wrong here
A PSK mismatch prevents phase1 negotiation, so phase1 would never reach 'up'; it cannot leave phase2 down. It is tempting because PSK errors are a common IPsec misconfiguration, and this option would be correct if phase1 status showed 'down' or the tunnel failed during main mode or aggressive mode authentication.
- ✗
The DPD settings are incompatible between the peers.
Why it's wrong here
DPD detects dead peers by sending R-U-THERE probes; it does not negotiate phase2 selectors, so mismatched DPD settings cannot leave phase1 up while phase2 stays down. It is tempting because DPD failures do tear tunnels down, but that occurs after establishment, when a peer stops responding.
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 718 original NSE7 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 →
Same concept, more angles
1 more way this is tested on NSE7
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A network administrator is troubleshooting an IPsec VPN between two FortiGates. The phase1 is up, but phase2 keeps failing to establish. The administrator runs 'diagnose vpn ike log' and sees: 'no proposal chosen'. Both sides have the same phase2 configuration: AES256-SHA256, DH group 14, 3600 seconds lifetime. What is the MOST likely cause?
hard- A.The NAT traversal setting is inconsistent
- B.The IKE version is different on each side
- ✓ C.The phase2 local and remote subnets do not match on both sides
- D.The pre-shared key is incorrect
Why C: Even if the encryption/authentication proposals match, a common issue is a mismatch in the local and remote subnets (selectors). The phase2 negotiation requires matching traffic selectors. If one side has 192.168.1.0/24 and the other has 10.0.0.0/8, the proposals will be rejected. Option C is correct.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE7 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 NSE7 exam.