NSE4 Authentication and VPN Practice Question
A network admin configures a site-to-site IPsec VPN between two FortiGates using IKEv1 main mode. The tunnel establishes successfully, but no traffic passes. What is the MOST likely cause?
⚠ Common exam trap
Candidates often assume a successful IPsec tunnel automatically allows traffic, but FortiGate requires an explicit firewall policy to permit traffic through the VPN interface, unlike some other vendors where the tunnel itself implies a permit.
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
✓
There is no firewall policy allowing traffic through the VPN tunnel
The tunnel establishes successfully, meaning IKE phase 1 and phase 2 negotiations completed correctly, which rules out mismatched proposals or incorrect pre-shared keys. However, even with a functional IPsec tunnel, traffic cannot flow unless a firewall policy explicitly permits it between the source and destination zones using the VPN interface. In FortiGate, the VPN tunnel is treated as an interface, and without a policy allowing traffic from the internal network to the VPN interface (or vice versa), packets are dropped by the firewall engine.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Aggressive mode should be used instead of main mode
Why it's wrong here
Main mode and aggressive mode are IKE phase 1 negotiation methods that differ in how many packets are exchanged and how identity is protected, but neither affects the data plane after the tunnel is up. Once all IKE SAs and IPsec SAs are established, the encapsulated packets are sent and received identically regardless of the negotiation mode. Since the symptom is that the tunnel appears established but traffic does not flow, switching from main mode to aggressive mode would not change the result; it would also unnecessarily weaken security by transmitting the identity in clear during negotiation.
- ✗
The pre-shared key is incorrect
Why it's wrong here
The pre-shared key is used in IKE phase 1 to authenticate the two peers and generate the same keying material. If the PSKs do not match on each side, phase 1 authentication fails with a payload mismatch or hash validation error, so the tunnel can never reach an established state. In this scenario the tunnel is already up, meaning the peers have successfully authenticated each other, so a wrong PSK cannot be the cause; the IKE SA could not have been established in the first place if the PSK were incorrect.
- ✓
There is no firewall policy allowing traffic through the VPN tunnel
Why this is correct
Even when the IPsec tunnel interface is up and phase 1/phase 2 SAs are active, FortiGate will not forward any user traffic through the tunnel unless an explicit firewall policy permits it. The policy must be configured with the source address, destination address, and service, and its outgoing interface must be set to the VPN tunnel interface (or the virtual IPsec interface). Without such a policy, packets are dropped at the firewall policy check even though the encrypted tunnel exists and is healthy. This is the classic root cause when the VPN shows connected but users cannot reach remote resources, and the fix is to create the appropriate ACCEPT policy from the local zone to the VPN zone.
- ✗
The phase2 proposal does not match between peers
Why it's wrong here
The phase 2 proposal defines the IPsec SA parameters such as encryption algorithm, authentication algorithm, and DH group used for the data traffic. If the proposals do not match between peers, the phase 2 quick mode exchange will fail, leaving the tunnel in a negotiated-only or down state—it would never show as fully established. Since the problem statement indicates the tunnel is established, phase 2 must have completed successfully. Therefore a phase 2 proposal mismatch would be mutually exclusive with the observed symptom, and the actual issue must instead be a missing firewall policy that is needed to permit traffic into the tunnel.
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
Courseiva writes every NSE4 question from scratch — 282 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.