NSE4 Authentication and VPN Practice Question
A FortiGate in a hub-and-spoke VPN topology has multiple spoke sites connecting via IPsec. The hub administrator wants to enable direct spoke-to-spoke communication without routing traffic through the hub. What technology should be used?
⚠ Common exam trap
Candidates often confuse ADVPN with simply adding more Phase 2 selectors to an existing tunnel, thinking that will magically route traffic directly between spokes, when in fact Phase 2 selectors only control encryption policies, not tunnel establishment.
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
✓
ADVPN (Auto-Discovery VPN)
ADVPN (Auto-Discovery VPN) is the correct technology because it dynamically establishes direct IPsec tunnels between spoke sites in a hub-and-spoke topology, eliminating the need to route inter-spoke traffic through the hub. It uses IKEv2 with short-cut messages (via the hub as a signaling broker) to allow spokes to learn each other's public IP addresses and negotiate a direct tunnel, reducing latency and hub load.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
ADVPN (Auto-Discovery VPN)
Why this is correct
ADVPN (Auto-Discovery VPN) is the correct dynamic solution. It builds on a standard hub-and-spoke IPsec topology, where the hub acts as a route reflector and triggers short-cut negotiations between spokes via IKE informational exchanges when inter-spoke traffic is detected. This allows spokes to dynamically establish direct IPsec tunnels, eliminating the need for traffic to hairpin through the hub and providing optimal routing and reduced latency.
- ✗
Site-to-site VPN between each spoke pair manually
Why it's wrong here
Manually configuring site-to-site VPN tunnels between every spoke pair is technically possible, but it is a static, full-mesh approach that requires N*(N-1)/2 separate tunnels for N spokes. This not only fails to adapt to network changes or new spokes, but also multiplies configuration complexity and troubleshooting overhead, making it impractical for any hub-and-spoke topology beyond the smallest deployments. It does not employ any auto-discovery mechanism, so it cannot scale or respond dynamically.
- ✗
Policy-based VPN with multiple Phase 2 selectors
Why it's wrong here
A policy-based VPN with multiple Phase 2 selectors defines multiple interesting traffic pairs between a fixed set of endpoints, typically a hub and a spoke. It is a static, centrally configured approach that cannot trigger dynamic direct tunnels between spokes; the hub must always relay inter-spoke traffic, and each Phase 2 selector merely specifies which source/destination subnets are protected over an already-established tunnel. This lacks the IKE-based shortcut negotiation that ADVPN uses to create on-demand spoke-to-spoke paths.
- ✗
SSL VPN tunnel mode
Why it's wrong here
SSL VPN tunnel mode is designed for remote end-user clients (e.g., FortiClient) to securely access internal resources through a single VPN gateway, not for site-to-site connectivity between network appliances. It would require each spoke to act as a VPN client to the hub or to other spokes, which is architecturally incorrect and inefficient, and it does not support dynamic route exchange or automatic tunnel establishment between spokes. Thus, it cannot solve the problem of enabling dynamic direct spoke-to-spoke traffic in a hub-and-spoke VPN.
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.