A utility's NOC engineer is building a new site-to-site IPsec tunnel to a remote substation FortiGate. During IKE phase 1, the two devices must agree on how to protect the negotiation itself before any user traffic can be defined. Which set of parameters is negotiated in phase 1?
Select an answer to reveal the explanation.
Short Explanation
Picture phase 1 as the two FortiGates agreeing on a secret handshake before they say anything sensitive to each other. That handshake covers encryption, hashing, and the Diffie-Hellman group used to build a protected channel between the NOC and the substation box. Only after that channel exists does phase 2 talk about which actual traffic gets to ride inside it.
Full Explanation
IKE phase 1 establishes the secure, authenticated management channel between the two VPN peers — the NOC FortiGate and the substation FortiGate negotiate an encryption algorithm, an authentication/hash algorithm, and a Diffie-Hellman group, and they authenticate each other using either a pre-shared key or certificates. Nothing about the actual data traffic is decided yet; phase 1 is purely peer-to-peer trust and key material for the control channel. The proxy-ID option describes phase 2, where the source and destination subnets (or a wildcard/0.0.0.0 selector for route-based tunnels) are defined so the tunnel knows what interesting traffic to encrypt. The routing-protocol option is a separate, later step: once the tunnel interface is up, an admin may choose to run OSPF or a static route over it, but that has nothing to do with what phase 1 negotiates. Firewall policies are also a downstream requirement — a tunnel interface still needs policies permitting traffic in and out, but that configuration happens after the tunnel is established, not during phase 1. A quick operational check is to run 'diagnose vpn ike gateway list' on the FortiGate, which shows whether phase 1 completed and which parameters were actually agreed on with the peer.