NSE4 Authentication and VPN Practice Question
A FortiGate in a hub-and-spoke VPN topology is configured with a single IPsec tunnel to each spoke. The hub has a route-based VPN with a tunnel interface for each spoke. After a reboot, traffic between spoke A and spoke B fails, although each spoke can reach the hub. What is the likely cause?
⚠ Common exam trap
Test-takers frequently assume firewall policies are the only control for inter-spoke traffic, overlooking that route-based VPNs require explicit routing entries on the hub to forward traffic between spokes.
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 hub is missing static routes to the spoke networks via the respective tunnel interfaces
In a hub-and-spoke route-based VPN, the hub uses tunnel interfaces for each spoke. After a reboot, the hub's routing table is cleared, and without static routes pointing to the spoke networks via the respective tunnel interfaces, the hub cannot forward traffic between spokes. Even though each spoke can reach the hub, inter-spoke traffic requires the hub to have explicit routes to the remote spoke networks, as dynamic routing protocols are not mentioned in this scenario.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The hub is missing static routes to the spoke networks via the respective tunnel interfaces
Why this is correct
In route-based IPsec VPNs, the hub must have a static route for each spoke's protected network, pointing to the corresponding tunnel interface. Without these routes, the hub cannot determine the correct egress tunnel for inter-spoke packets, so even though the IPsec tunnels are established and firewall policies permit the traffic, the packets are dropped or never forwarded. After a reboot, these static routes are critical because they are not dynamically learned unless a routing protocol is running over the tunnel.
- ✗
The firewall policies on the hub do not allow traffic between the spoke networks
Why it's wrong here
If the firewall policies on the hub were the root cause, the inter-spoke traffic would be denied consistently, regardless of reboot state, and the hub would log denials. However, the issue here is that the hub cannot route the traffic to the next spoke, which is a forwarding problem, not a policy problem. Firewall policies are a necessary condition for any traffic to be allowed, but without routes, the packet is never even looked up against a policy because it fails the routing lookup.
- ✗
The spokes have mismatched IKE versions
Why it's wrong here
Mismatched IKE versions between the spokes and the hub would prevent the Phase 1 negotiation from completing, so none of the IPsec tunnels would come up at all. This would cause a total loss of connectivity, including spoke-to-hub traffic, not merely an inter-spoke communication failure after reboot. Since the spokes can still communicate with the hub, the IKE parameters, including version, must be correctly negotiated.
- ✗
The hub's IPsec Phase1 is not configured for DPD
Why it's wrong here
DPD (Dead Peer Detection) is used to detect whether the remote VPN peer is still reachable, typically by sending liveness probes. Not enabling DPD on the hub does not affect the forwarding plane or the routing table; it only means that dead peers are not detected quickly. A reboot would re-establish the tunnels, and DPD settings are not involved in the routing decision between spokes, so this cannot be the cause of the inter-spoke failure.
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.