A utility's NOC FortiGate has a route-based IPsec tunnel to a substation that is up and passing traffic. The security team notes that the tunnel interface alone does not restrict which hosts on the NOC side can reach which hosts on the substation side. What must still be configured for traffic to be properly controlled once it reaches the tunnel interface?

A route-based (interface-mode) IPsec tunnel creates a virtual tunnel interface, and like any FortiGate interface, that interface only provides Layer 3 connectivity — it does not by itself enforce which source and destination hosts are permitted to communicate. Firewall policies referencing the tunnel interface as the source or destination interface are still required to actually permit or deny traffic, exactly as they would be for a physical or VLAN interface; this is a common point of confusion because many administrators assume the tunnel's existence implies access control. Phase 1 defines the peer relationship and is not something re-negotiated per host pair, so adding phase 1 proposals per host is not how granular access is achieved, and doing so would not create finer-grained control anyway. Phase 2 selectors define which subnets are considered 'interesting traffic' for encryption purposes; when a route-based tunnel uses broad selectors like 0.0.0.0/0, that only affects what gets encrypted, not who is authorized to send it, so the fix is firewall policy, not narrower selectors per host. Assuming a route-based tunnel automatically restricts traffic to phase 2 subnets ignores that many route-based deployments intentionally use wide selectors and rely entirely on firewall policy for actual segmentation. To confirm, review 'config firewall policy' for entries with the tunnel's virtual interface as srcintf or dstintf, and use the policy lookup tool to verify a specific NOC-to-substation host pair is actually permitted.