FortiGate Site-to-Site IPsec VPN: Phase 1 and Phase 2 Setup

Site-to-site IPsec on FortiGate is built from two layers: phase 1 (IKE) negotiates the secure management channel and authenticates the peers, phase 2 (IPsec) negotiates the data tunnel and its traffic selectors. Most "tunnel is up but no traffic passes" incidents trace back to phase 2 selector mismatches or phase 1 algorithm drift between the two vendors. This guide walks a FortiGate-to-FortiGate site-to-site VPN with pre-shared key - the template also shows exactly what to check when the peer is a third-party firewall.

Phase 1 (IKE) Configuration

Phase 1 establishes the IKE SA. On FortiOS it is a vpn ipsec phase1-interface object bound to the WAN interface:

config vpn ipsec phase1-interface
    edit "HQ-to-BR"
        set interface "port2"
        set ike-version 2
        set keylife 28800
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set remote-gw 203.0.113.25
        set psksecret ENC <pre-shared-key>
    next
end

Key points: ike-version 2 is preferred for new builds (IKEv2 is faster and more robust); the proposal must overlap with the peer (aes256-sha256 is a safe common baseline; add more proposals when interop with old peers is needed); remote-gw is the peer's public IP.

Phase 2 (IPsec) Configuration

Phase 2 defines the encrypted data tunnel and its selectors - the local and remote subnets allowed through:

config vpn ipsec phase2-interface
    edit "HQ-to-BR-data"
        set phase1name "HQ-to-BR"
        set proposal aes256-sha256
        set pfs enable
        set keylifeseconds 3600
        set src-addr-type subnet
        set dst-addr-type subnet
        set src-subnet 192.168.20.0 255.255.255.0
        set dst-subnet 192.168.10.0 255.255.255.0
        set auto-negotiate enable
    next
end

The src-subnet/dst-subnet pair must mirror on the peer (its local LAN is your remote). Selector mismatches - for example one side using a /24 while the other lists a single host - produce a tunnel that negotiates but silently drops traffic. pfs enable with the same DH group as the peer avoids phase 2 negotiation failures.

Policy: IPsec Tunnels Need Firewall Policies

On FortiOS the tunnel itself carries no traffic until two policies exist - one per direction - matching the tunnel interface:

config firewall policy
    edit 1
        set name "BRANCH-LAN-IN"
        set srcintf "port2"
        set dstintf "HQ-to-BR"
        set srcaddr "all"          # or the remote LAN address object
        set dstaddr "local-lan-subnet"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

Forgetting the return policy (or the local-interface-to-tunnel policy on the branch unit) is the most common reason a freshly negotiated tunnel passes nothing.

Verification and Troubleshooting

diagnose vpn ike gateway list              # phase 1 SA state (up/down)
diagnose vpn tunnel list                   # phase 2 tunnels and selectors
get vpn ipsec tunnel summary
diagnose sniffer packet any 'host 203.0.113.25 and udp port 500' 4

Phase 1 down usually means proposal mismatch, wrong PSK or UDP 500/4500 blocked; phase 2 problems show as selector or PFS mismatches. Compare both sides' proposals systematically - the general IPsec debugging flow in our FortiOS CLI troubleshooting cheat sheet covers the full command set. For the equivalent configuration on other platforms see the Juniper SRX route-based IPsec guide and our Cisco ASA basics.

What Phase 1 and Phase 2 Actually Negotiate

It helps to be precise about the two layers, because the CLI split maps onto very different failure modes:

• Phase 1 / IKE SA - the control channel. It negotiates the encryption and authentication algorithms used for IKE itself, authenticates the two peers (pre-shared key or certificate), and agrees on the SA lifetime. If phase 1 is down, nothing else happens and no data tunnel can exist.
• Phase 2 / IPsec SA - the data channel. It negotiates the ESP proposal, the traffic selectors (which source and destination subnets are encrypted) and perfect forward secrecy. Phase 2 can negotiate successfully and still carry no traffic if the selectors do not match what the peers actually want to protect.

FortiGate binds both to a tunnel interface object: phase 1 defines the interface, phase 2 attaches subnets to it. Understanding that ordering is what makes the "tunnel is up but nothing pings" class of problem tractable instead of mysterious.

Address Objects and the Return Path

Rather than typing subnets inline, define address objects once and reference them from both phase 2 and the firewall policies. On the branch unit:

config firewall address
    edit "BRANCH-LAN"
        set subnet 192.168.20.0 255.255.255.0
    next
    edit "HQ-LAN"
        set subnet 192.168.10.0 255.255.255.0
    next
end

Then the tunnel selectors read from those objects, and a subnet change is one edit instead of a hunt through phase 2, policies and NAT rules. The same objects feed the firewall policies in both directions, which is exactly how the reverse tunnel policy is kept from drifting out of sync with the forward one - the most common cause of one-way tunnels.

The Branch Side and the Mirrored Selectors

Phase 2 needs to know both remote subnets, and the branch unit is configured as the mirror image of the head office:

config vpn ipsec phase2-interface
    edit "BR-to-HQ-data"
        set phase1name "BR-to-HQ"
        set proposal aes256-sha256
        set pfs enable
        set keylifeseconds 3600
        set src-addr-type subnet
        set dst-addr-type subnet
        set src-subnet 192.168.10.0 255.255.255.0
        set dst-subnet 192.168.20.0 255.255.255.0
        set auto-negotiate enable
    next
end

Note the selector swap: the branch's src-subnet is the HQ LAN and its dst-subnet is the branch LAN, the exact inverse of the HQ configuration. When only one side lists a selector, the quick-mode proposal is rejected outright. A route-based tunnel additionally needs a static route pointing at the tunnel interface for the remote subnet:

config router static
    edit 0
        set dst 192.168.10.0 255.255.255.0
        set device "BR-to-HQ"
    next
end

Without that route the encryption domain exists but FortiGate has no reason to put the packet into the tunnel, and the failure looks identical to a policy problem from the client's point of view.

NAT-T and the Front-End Router

If either peer sits behind a NAT device - a common ISP router or a CGNAT access link - IKE and ESP must traverse it. Enable NAT traversal and let FortiGate handle the resulting fragmentation quirks:

config vpn ipsec phase1-interface
    edit "HQ-to-BR"
        set nattraversal enable
        set fragmentation enable
        set dpd on-idle
        set dpd-retrycount 3
        set dpd-retryinterval 5
    next
end

NAT-T wraps ESP inside UDP port 4500 so a middlebox can track the flow as a single UDP session, and set fragmentation enable handles frames that exceed the tunnel MTU without relying solely on path MTU discovery - which NAT devices frequently break, producing the classic "small packets work, large ones silently vanish" symptom. Confirm the upstream router forwards UDP 500 and 4500 to the FortiGate as well; a firewall that is perfectly willing to terminate IKE will still never see it if the edge drops the ports.

Dead Peer Detection and Tunnel Recovery

DPD is what brings a healthy tunnel back after an outage that never involved the FortiGate. With set dpd on-idle, probes are only sent when there is no other traffic, which avoids needless keepalives on a busy link; dpd-retrycount and dpd-retryinterval decide how many missed probes and how long between them before the SA is torn down and rebuilt.

Use set dpd on-demand when you would rather the tunnel be torn down whenever it goes idle and rebuilt only when traffic arrives. That is the right mode for a low-traffic branch backup link where holding an SA open all month is wasted state on both peers. Whichever mode you choose, make sure the setting is mirrored on the far side: a peer with DPD disabled will never notice a silent path failure, so the tunnel can appear up on both sides while passing nothing.

Monitoring and Logging the Tunnel

diagnose vpn ike gateway list
diagnose vpn tunnel list
get vpn ipsec tunnel summary
diagnose debug application ike -1
diagnose debug enable

diagnose debug application ike prints the IKE negotiation live, which is what you want when a tunnel will not come up at all - it shows the proposal the peer offered beside the one FortiGate accepted or rejected, turning an algorithm mismatch into a visible diff. Turn it off with diagnose debug disable when you are done, because it is verbose. For ongoing visibility, add set logtraffic all to the tunnel policies and watch the session counters; a policy showing zero sessions is a routing or policy problem rather than a crypto one, and that distinction decides which half of the configuration you go and check.

Interoperating with a Third-Party Peer

The most common real-world variant is a FortiGate on one end and a different vendor on the other. The negotiation logic is identical, but a few cosmetic differences trip people up:

• Algorithm naming differs. Cisco and Palo Alto describe the phase 2 suite as a transform set or IPsec proposal with separate encryption and hash fields; a FortiGate proposal aes256-sha256 is the same thing expressed in one string.
• Some platforms still default to IKEv1 and need an explicit IKEv2 toggle. Confirm the version on both ends before debugging anything else, because a version mismatch produces a phase 1 failure that looks exactly like a proposal mismatch.
• PFS and the DH group must match exactly. A FortiGate with pfs enable facing a peer with PFS off will fail phase 2 every time.

For concrete syntax on the other side see the Palo Alto site-to-site IPsec CLI configuration, the Cisco ASA site-to-site IPsec VPN CLI configuration and the MikroTik RouterOS 7 IPsec site-to-site setup.

Common Failure Signatures

• Phase 1 never comes up. Algorithm mismatch, wrong pre-shared key, or UDP 500/4500 blocked by an edge device. Read diagnose vpn ike gateway list for the negotiated proposal and compare both sides line by line.
• Phase 1 up, phase 2 down. Selector or PFS mismatch. The diagnose vpn tunnel list output shows the quick-mode selectors each side proposed, which is usually enough to spot the difference immediately.
• Both up, no traffic. A missing route into the tunnel interface, or a missing return firewall policy on the far side. Confirm with a policy lookup and a packet sniffer before touching the crypto configuration.
• Traffic flows briefly then stalls. Almost always MTU. A large packet enters the tunnel, PMTUD is blocked by a NAT device, and the connection hangs. Lower the tunnel MTU or enable fragmentation.
• Repeated rekey failures. Key lifetimes or PFS settings disagree. Align keylife and keylifeseconds and the DH group on both ends.

The debug flow in the IPsec IKEv2 SA_INIT and IKE_AUTH troubleshooting guide walks the same negotiation at the packet level and reads well alongside the CLI commands above.

Hardening the VPN

• Prefer certificates over pre-shared keys where the peer supports it. A PSK shared across dozens of branches is a single point of compromise.
• Use IKEv2 and disable aggressive mode and IKEv1 if no peer requires them.
• Retire 3DES, SHA1 and DH group 2. AES-256 with SHA-256 and a group 14 or higher DH is the sensible floor for new builds.
• Keep the phase 1 lifetime longer than phase 2 - 28800 seconds against 3600 seconds is the usual convention - so rekeys stay cheap and infrequent.
• Restrict phase 2 selectors to the subnets you actually protect. Never use 0.0.0.0/0 on both ends unless you have deliberately designed a full-tunnel topology.
• Log and alert on tunnel-down syslog events so an outage is noticed before a user calls the helpdesk.

原文链接：https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/913287/basic-site-to-site-vpn-with-pre-shared-key