NSE4 Authentication and VPN Practice Question
When configuring a route-based IPsec VPN, which of the following must be created to allow traffic to flow through the tunnel?
⚠ Common exam trap
A common mix-up: candidates confuse route-based VPNs with policy-based VPNs, mistakenly thinking that a firewall policy alone is sufficient to direct traffic into the tunnel, when in fact the route is the critical component that enables the forwarding decision in a route-based design.
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
✓
A static route to the remote subnet via the IPsec interface
In a route-based IPsec VPN, the tunnel is represented as a virtual IPsec interface. To route traffic from the local network to the remote subnet through this tunnel, a static route must be configured with the remote subnet as the destination and the IPsec interface as the next-hop or outgoing interface. Without this route, the FortiGate has no forwarding information to send traffic into the tunnel, even if the IPsec phase 1 and phase 2 settings are correctly established.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
A static route to the remote subnet via the IPsec interface
Why this is correct
The static route is the core requirement in route-based IPsec VPN because the IPsec tunnel is bound to a virtual interface (e.g., s2s_ike). Without a route directing the remote subnet's destination IPs to that interface, the FortiGate has no next-hop to forward traffic into the tunnel, so packets are dropped by the routing decision. While a firewall policy must also exist to permit the traffic, it is the route that actually enforces the "remote subnet via IPsec interface" path, and traffic that doesn't follow this route remains unencrypted and may be routed incorrectly.
- ✗
A firewall policy with the VPN interface as source
Why it's wrong here
A firewall policy's source and destination interfaces only define the security zones and permit/deny logic; they do not influence the routing decision. In route-based VPN, you can indeed set the incoming interface to the VPN interface and outgoing to an internal interface (or vice versa), but without a matching route to the remote subnet via the IPsec interface, the FortiGate will not know to send the packet into the tunnel, and the traffic will never reach the policy inspection. The policy alone cannot create a path or encapsulate traffic; it merely accepts or rejects traffic that the routing table already forwarded.
- ✗
A NAT rule to translate the private IPs
Why it's wrong here
A NAT rule misinterprets the typical site-to-site VPN design. In IPsec site-to-site configurations, the private networks on both ends are usually routed directly with no source or destination NAT, because translating addresses would break the peer's routing entries and the security associations (SAs). If a NAT rule were applied to VPN traffic, the FortiGate would likely translate the source to its own WAN IP, causing the remote gateway to see an unexpected address and drop the session. Thus, NAT is both unnecessary and often counterproductive; the question asks for the required component, and NAT is explicitly not required unless special overlap scenarios exist.
- ✗
A security profile for VPN traffic
Why it's wrong here
Security profiles (IPS, antivirus, web filtering, etc.) are added to firewall policies to inspect traffic, but they are optional for basic IPsec connectivity. A minimal policy that permits traffic between internal and VPN interfaces, with no security profiles attached, will still establish the tunnel and forward encrypted packets. Profiles are applied only after the packets are routed to the IPsec interface and decapsulated, so they have no role in the initial route-based setup. The question specifically tests routing requirements, and selecting a security profile would be a mistaken substitution that misses the essential static route.
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
Courseiva writes every NSE4 question from scratch — 773 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.