A utility wants to add a new substation to its hub-and-spoke IPsec design and later run a dynamic routing protocol over the tunnel to automatically advertise reachable subnets. Which IPsec configuration approach best supports this goal?
Select an answer to reveal the explanation.
Short Explanation
Think of route-based IPsec as building a real virtual interface — like a virtual Ethernet cable — that the FortiGate can drop into its routing table and run OSPF or static routes over. Policy-based IPsec, by contrast, ties encryption directly to a firewall policy with no interface for a routing protocol to attach to.
Full Explanation
Route-based (interface-mode) IPsec creates a virtual tunnel interface (VTI) that behaves like any other FortiGate interface: it can be assigned to a zone, referenced by static or policy routes, and it can run a dynamic routing protocol such as OSPF, letting a new substation's subnets be advertised automatically as spokes are added to a hub-and-spoke design. Policy-based IPsec has no such interface — encryption is bound directly to the phase 1/phase 2 definitions referenced inside a firewall policy, so there is nothing for a routing protocol to run over, which makes the first distractor's claim about automatic redistribution incorrect. The second distractor inverts a real limitation: it is actually route-based tunnels, using selectors of 0.0.0.0/0, that scale cleanly to many subnets without redefining phase 2 per subnet, not policy-based tunnels. Aggressive versus main mode is a phase 1 negotiation-mode choice affecting how quickly and how visibly peer identities are exchanged; it has no bearing on whether the tunnel is route-based or policy-based, so tying the correct mode to aggressive mode is a fabricated dependency. To confirm a tunnel is route-based, check the CLI for a corresponding virtual interface under 'config system interface' with type set to tunnel, and verify it appears in 'get router info routing-table all' once a routing protocol or static route references it.