NSE4 Authentication and VPN Practice Question
A FortiGate is configured with IPsec VPN using IKEv2 and a policy-based tunnel. The remote subnet is 10.0.2.0/24, and the local subnet is 192.168.1.0/24. The tunnel is up, but traffic from 192.168.1.0/24 to 10.0.2.0/24 fails. The administrator checks the firewall policy and sees a policy allowing traffic from the local interface (port1) to the remote interface (virtual ipsec interface) with the action set to IPSEC. What is the most likely missing configuration?
⚠ Common exam trap
Many exam-takers assume a tunnel being up means all traffic will pass, but FortiGate policy-based VPNs require the firewall policy's address objects to precisely match the protected subnets, not just the tunnel interface.
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 firewall policy's source or destination addresses are not correctly set to the local and remote subnets
In a policy-based IPsec VPN on FortiGate, the firewall policy must explicitly specify the local and remote subnets as the source and destination addresses. Even if the tunnel is up, traffic will fail if the policy's source/destination address objects do not match the actual subnets (192.168.1.0/24 and 10.0.2.0/24). The action set to IPSEC only enables VPN encapsulation; it does not override incorrect address matching.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
IKEv2 does not support policy-based VPNs
Why it's wrong here
IKEv2 is a key exchange protocol that is independent of the VPN mode; FortiOS supports both route-based and policy-based IPsec VPNs using IKEv2. The claim that IKEv2 disallows policy-based VPNs is false—policy-based configurations still work with IKEv2 because the Phase 2 proxy-IDs carry the selector information. Therefore, this is not the cause of the failure.
- ✗
The tunnel interface is not assigned to the correct VDOM
Why it's wrong here
In a policy-based IPsec VPN, no tunnel interface is created or used; the tunnel itself is referenced directly in the firewall policy. Thus, assigning a tunnel interface to a VDOM is irrelevant for this scenario. Even in route-based VPNs, an incorrect VDOM assignment would prevent the interface from being valid, but the tunnel being up indicates the interface is properly placed and usable.
- ✗
The Phase 2 proposal does not match the remote subnet
Why it's wrong here
Phase 2 proposals (encryption, authentication, DH group, and encapsulation) define the security association parameters, not the subnets that traverse the tunnel. The local and remote subnets are maintained separately in the Phase 2 selectors (proxy-IDs), which are distinct from the proposal algorithms. A subnet mismatch would manifest as a Phase 2 negotiation failure, not as a firewall policy issue, so this option misidentifies the failure domain.
- ✓
The firewall policy's source or destination addresses are not correctly set to the local and remote subnets
Why this is correct
In a policy-based IPsec VPN, the firewall policy itself defines the local and remote subnets through its source and destination address objects, effectively acting as the Phase 2 proxy-IDs. If those address objects do not exactly match the subnets to be protected, the tunnel remains up but traffic is not matched by the policy, so the FortiGate drops or fails to forward it. Additionally, using only 'all' as the destination may send a proxy-ID of 0.0.0.0/0, which many remote peers reject, causing a negotiation mismatch even though the policy itself is permissive.
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.