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.

• ✓

  Use a single Phase 2 selector with 0.0.0.0/0.0.0.0 for both local and remote

  Why this is correct

  Setting both local and remote Phase 2 selectors to 0.0.0.0/0 creates an any-to-any proxy ID, so all traffic routed into the tunnel interface is encrypted without needing a separate selector per subnet or per spoke. In a route-based VPN, the tunnel interface decouples routing from IPsec proxy IDs, so a single Phase 2 definition can be reused across every spoke; new spokes simply reuse the same selector and rely on routing to direct traffic. This is the standard FortiGate recommendation for hub-and-spoke because it avoids negotiation failures caused by mismatched local/remote subnet definitions and eliminates per-spoke Phase 2 configuration at the hub.

• ✗

  Configure each spoke in a separate VDOM

  Why it's wrong here

  Placing each spoke in a separate VDOM at the hub would partition the FortiGate into multiple independent virtual firewalls, each requiring its own routing table, firewall policies, address objects, and IPsec configuration. That adds administrative overhead and does nothing to consolidate the Phase 2 selector issue; every VDOM would still need its own Phase 2 settings, and inter-VDOM traffic would need extra links or policies. VDOMs are a security and administrative isolation tool, not a method for simplifying VPN selector management, so this option increases complexity rather than reducing it.

• ✗

  Use aggressive mode for Phase 1

  Why it's wrong here

  IKE Phase 1 aggressive mode shortens the initial key exchange from six to three packets by omitting identity protection and sending the preshared key (in hashed form) during the first exchange. However, Phase 2 quick mode is a completely separate negotiation that carries the proxy IDs (local and remote selectors); aggressive mode has no effect on how Phase 2 selectors are defined or matched. Therefore, using aggressive mode would not simplify Phase 2 configuration, and it would actually reduce security by making the PSK vulnerable to offline dictionary attacks, especially when shared across multiple spokes.

• ✗

  Use policy-based VPN instead of route-based

  Why it's wrong here

  Policy-based VPNs bind Phase 2 selectors to individual firewall policies, so adding a new spoke would require manually creating a new policy and selector pair for each subnet pair at the hub, offering no simplification over the existing Phase 2 selector approach. This option is tempting because policy-based VPNs are the correct choice when you need per-protocol or per-port granularity in tunnel selection, such as separating voice and data traffic over distinct IPsec SAs, which is not the requirement here.

Go deeper

Related to this question