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.

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