A customer has its own PI range of public IP addresses, and they way to use part of this range in a remote office and place some servers there. The remote office is connected via some third-party ISP. So, the VPN tunnel should route the customer’s addresses and provide full Internet access to the remote office. Both sides should use Fortinet’s FortiGate firewalls.
It is quite natural to use a policy-based VPN for the remote side: the policy would match “all” destination addresses, and send all Internet traffic to the IPSec tunnel. But the central site is a firewall on a stick, so both Internet and IPSec traffic are going through the same wan1 interface.
Professional support at a local Fortinet partner gave an idea that I could not derive from any documentation: policy-based VPN and interface-based VPN can work together within the same IPSec tunnel.
So, the remote site is configured with policy-based VPN. The tunnel’s Phase 2 selector is 0.0.0.0/0.0.0.0 for both source and destination. The VPN policy matches all traffic from the local LAN addresses to “all”.
The central site is configured as interface-based VPN. The tunnel is pointing to a dynamic DNS endpoint, and the Phase 2 selector is also 0.0.0.0/0.0.0.0 (as it must match the selector on the other side of the tunnel). Then, it’s accomplished with in- and outbound policies that “ACCEPT” all traffic from and to the remote LAN, and a static route that sends all traffic toward remote LAN through the tunnel.