An OT maintenance vendor needs a permanent site-to-site IPsec tunnel into a utility's substation network so its engineers can remotely service protective relays. The vendor's edge device has a dynamic, unpredictable public IP address, while the utility's NOC FortiGate has a fixed IP. How should the NOC FortiGate be configured for phase 1?
Select an answer to reveal the explanation.
Short Explanation
When the far end's address can move around, the NOC FortiGate can't just type in an IP and hope it stays put. That's exactly what dialup (dynamic) phase 1 is for: the NOC waits for the vendor's box to call in and identifies it by a peer ID or certificate instead of a fixed address.
Full Explanation
When a remote IPsec peer has a dynamic or unknown public IP address, the local FortiGate configures that phase 1 as a dialup (dynamic) gateway, meaning it does not pre-specify a remote IP and instead accepts an incoming negotiation from any address, authenticating the peer using a pre-shared key tied to a peer ID, or a certificate, rather than by source address. This is a standard pattern for connecting a third-party vendor's device whose IP cannot be guaranteed in advance. Manually updating a static IP entry every time the vendor's address changes is operationally fragile and defeats the purpose of a stable, low-touch tunnel — it also would cause outages between updates. Tying dialup mode to policy-based IPsec specifically is a fabricated constraint; dialup phase 1 gateways work with both route-based and policy-based configurations, so the mode of the tunnel is a separate decision from how the peer is identified. Dialup mode is also not exclusive to FortiClient SSL VPN users — FortiGate-to-FortiGate IPsec tunnels commonly use dialup phase 1 when one side is dynamic. To confirm which mode is active, check 'config vpn ipsec phase1-interface' for the 'type' field set to 'dynamic', and review 'diagnose vpn ike gateway list' to see the peer ID presented at negotiation time.