With a dialup IPsec VPN on FortiGate, when add-route is enabled, FortiGate will only install the corresponding route when it has enough negotiated information from the tunnel. In FortiOS 7.6, that means the route is tied to the Phase 2 (Quick Mode) selectors and is created dynamically when the IPsec SA is actually up.
B. The administrator must ensure phase 2 is successfully established
This is required. FortiGate does not install the add-route route just because Phase 1 exists or because the configuration is present. The route is added when the tunnel is effectively usable, which requires Phase 2 (IPsec SA) to be up. If Phase 2 is not established, there is no active SA and FortiGate will not inject the related route into the routing table.
So, if the static route is not showing, one correct explanation is that Phase 2 is not up.
C. The administrator must define the remote network correctly in the phase 2 selectors
This is also required. For dialup tunnels, FortiGate derives what route to add from the remote subnet(s) defined in the Phase 2 selector (proxy ID). If the remote network in Phase 2 is missing, incorrect, or too broad/too narrow in a way that prevents negotiation, the tunnel either won’t come up (so no route), or the route that would be installed won’t match what the administrator expects.
So, another correct explanation is that the Phase 2 remote network is not correctly defined, preventing the correct route from being created.
Why the other options are incorrect
A. Policy route instead of a static route
Add-route does not require policy routes. It is specifically a feature that injects a route (route-table entry) associated with the IPsec tunnel/SA and the Phase 2 selector networks.
D. Enable a dynamic routing protocol
Dynamic routing protocols (OSPF/BGP/RIP) are not required for add-route. Add-route is independent of dynamic routing and works by installing routes locally based on the negotiated selectors.
