NSE4 Authentication and VPN Practice Question
You have a hub-and-spoke IPsec VPN with 10 spokes. The central FortiGate (hub) has 10 phase2 selectors, one for each spoke. You need to add a new spoke. What is the MOST efficient way to configure the hub?
⚠ Common exam trap
Candidates often think adding a new phase2 selector (Option B) is the simplest solution, but they overlook the scalability and maintenance burden, while the 0.0.0.0/0 selector (Option D) is mistakenly assumed to work in policy-based VPNs without understanding that it requires a route-based design to function correctly.
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
✓
Configure a route-based VPN and use dynamic routing protocols to advertise routes
A route-based VPN with dynamic routing (e.g., BGP or OSPF) is the most efficient approach because it eliminates the need to manually add a new phase2 selector for each new spoke. The hub can automatically learn the spoke's routes via the dynamic routing protocol, and the single phase2 selector (0.0.0.0/0) covers all traffic, simplifying configuration and scaling. This design also supports redundancy and load balancing across multiple spokes without reconfiguring the hub.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure a route-based VPN and use dynamic routing protocols to advertise routes
Why this is correct
Route-based VPNs abstract the tunnel as a virtual interface, so you can run a dynamic routing protocol like BGP or OSPF across it to advertise learned routes automatically. When a new spoke is added, the hub only needs to form a routing adjacency with that spoke, and the spoke's subnets are injected into the hub's routing table without touching phase2 selectors or traffic policies. This is the only option that truly scales to 10+ spokes because routing information propagates dynamically, eliminating per-spoke manual configuration.
- ✗
Add another phase2 selector for the new spoke
Why it's wrong here
Adding another phase2 selector manually works for one or two spokes, but each new spoke requires the hub to have a unique proxy ID pair defining the local and remote subnets for that tunnel. With 10 spokes, you must create and maintain 10 distinct phase2 selectors, and any change to a spoke's subnet (like adding a new VLAN) forces you to edit that selector and re-establish the phase2 SA. This is a static, per-connection approach that does not scale and introduces human error as the number of spokes grows.
- ✗
Replace all phase2 selectors with a single policy-based VPN
Why it's wrong here
A policy-based VPN is still bound to a pair of proxy IDs (the traffic selectors), not to a single global policy. If you attempt to use a single policy-based VPN for all spokes, you still need individual policies or selectors for each spoke's subnet combination, because the VPN device matches traffic based on both source and destination addresses. Moreover, policy-based VPNs do not support dynamic routing protocols over the tunnel, so you would still have to manually configure every spoke's interesting traffic on the hub, making this just as labor-intensive as option B.
- ✗
Use a single phase2 selector with 0.0.0.0/0.0.0.0 for all spokes
Why it's wrong here
Using 0.0.0.0/0.0.0.0 as a phase2 selector for all spokes creates overlapping proxy IDs across every tunnel, causing the hub's IPsec engine to be unable to uniquely map an incoming packet to the correct originating spoke. When replies are sent, the hub may choose the wrong SA or drop the packet because multiple tunnels match the same selector, resulting in intermittent connectivity or black-holing traffic. It also violates least-privilege security by exposing all subnets to all spokes, and it complicates VPN diagnostics significantly.
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.