NSE4 Authentication and VPN Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Change the IPsec mode from policy-based to route-based

  Why it's wrong here

  Switching from policy-based to route-based IPsec changes how tunnels are tied to firewall policies and routes, but it does not resolve the core problem: the hub's Phase 2 selectors still must include the source and destination subnets for inter-spoke traffic. A route-based VPN would let you route traffic into the tunnel via a route table, but unless the Phase 2 selectors on each spoke-to-hub tunnel encompass both the local spoke subnet and the remote spoke subnet, the hub will not re-encapsulate the packets into the other tunnel. Firewall policies also remain mandatory to permit forwarding between spokes, so the mode change alone is insufficient.

• ✓

  Modify the Phase 2 selectors on the hub to include both spoke subnets and add firewall policies allowing traffic between the spoke networks

  Why this is correct

  The correct fix is to ensure the hub's Phase 2 selectors for each spoke tunnel define traffic selectors that include both hub-side and remote-spoke subnets, so the hub can decapsulate traffic from one spoke, match it against the phase2 selectors of the other spoke's tunnel, and re-encapsulate it for forwarding. Additionally, the hub must have firewall policies that explicitly allow traffic between the spoke networks—typically by placing each spoke interface in a zone and permitting the traffic between them or using address objects. Without both the expanded selectors and the inter-spoke firewall policy, packets arriving from one spoke for the other will be dropped, as the hub either lacks the matching phase2 selector or the policy permission to forward the traffic.

• ✗

  Enable 'add-route' on the hub's Phase 1 settings

  Why it's wrong here

  Enabling 'add-route' on the hub's Phase 1 settings merely instructs FortiGate to dynamically add a static route for the peer's subnet(s) as learned from the Phase 2 selectors. This only creates a route on the hub to reach each spoke's private network; it does nothing to modify the Phase 2 selectors themselves, so the hub still lacks the necessary traffic selectors to forward packets from one spoke to another. Furthermore, 'add-route' cannot create firewall policies, so even if the hub knew the path to the other spoke, the traffic would still be blocked unless an explicit inter-spoke policy exists. The core issue remains both selector and policy configuration, not merely the presence of a route.

• ✗

  Configure a static route on each spoke pointing to the other spoke's subnet via the tunnel

  Why it's wrong here

  Adding a static route on each spoke pointing to the other spoke's subnet via the tunnel is misguided because spokes do not have a direct VPN tunnel to one another; each spoke only has a tunnel to the hub, so a route 'via the tunnel' would still send the traffic to the hub for forwarding. The real problem lies in the hub's configuration: it needs Phase 2 selectors that include both spoke subnets for each tunnel and an inter-spoke firewall policy to permit the traffic. While a spoke may need a route to the other spoke's subnet (often via a default route to the VPN or a specific static route to the hub), that route alone does not fix the hub's inability to re-encrypt and forward the traffic between tunnels. Thus, this option misplaces the critical configuration changes on the spokes rather than on the hub.

Go deeper

Related to this question