← Back to knowledge base
high

Troubleshooting an IPsec VPN with diagnose vpn ike config list

Confirmed 8/8/2026

Problem

An IPsec VPN tunnel does not establish. Common reasons include mismatched Phase 1 or Phase 2 settings between the two VPN peers, an incorrect configuration, or missing firewall policies.

Symptoms

The IPsec tunnel remains down, or `status.operational` reports `down`. The diagnostic output may also show `policy: no`.

Environment

FortiGate IPsec VPN. The command is especially useful when both peers are FortiGate devices because their effective configurations can be compared directly. It also identifies the VDOM containing the VPN in multi-VDOM deployments.

FortiOS version

FortiGate v6.4, FortiGate v7.0, FortiGate v7.2. Additional transport and QKD output fields apply starting with FortiOS 7.4.2.

Root Cause

Possible causes include an IKE version mismatch, wrong VPN type, incorrect local or remote peer address, main/aggressive mode mismatch, incompatible authentication or Diffie-Hellman settings, Phase 2 parameter mismatch, incorrect ADVPN roles, or absent firewall policies. At least one configured Diffie-Hellman group must match the remote FortiGate or third-party peer.

Solution

  1. Run the following command on the FortiGate whose tunnel is not coming up:
diagnose vpn ike config list
  1. If both VPN endpoints are FortiGate devices, run the same command on both peers and compare the results. A representative output is:
vd: root/0
name: VPN_ospf
serial: 2
version: 1
status.admin: up
status.operational: up
type: static
local: 10.xxx.17.23
remote: 10.xxx.16.190
mode: main
dpd: on-demand retry-count 3 interval 20000ms
auth: psk
dhgrp: 14 5
fragmentation: enable
xauth: none
interface: wan
virtual-interface-addr: 192.240.240.1 -> 192.240.240.2
auto-discovery-sender: disable
auto-discovery-receiver: disable
phase2s:
VPN_ospf proto 0 src VPN_ospf_local:0 dst VPN_ospf_remote:0 dhgrp 14 5 replay keep-alive auto-negotiate route-new
policy: yes
  1. Review each Phase 1 field:

    • vd: root/0: VDOM name and ID in which VPN_ospf is configured. In a multi-VDOM environment, verify that the VPN is in the intended VDOM.
    • name: VPN_ospf: Phase 1 or VPN name.
    • version: 1: IKE version. Both peers must use compatible IKE versions.
    • status.admin: up: Administrative state of the VPN interface.
    • status.operational: up: Operational state; this displays down when the VPN is down.
    • type: static: Configured VPN type. Confirm that static or dynamic is the intended type.
    • local: 10.xxx.17.23: Local source address for the tunnel.
    • remote: 10.xxx.16.190: Remote peer or tunnel termination address.
    • mode: main: IKE mode. Compare main mode or aggressive mode between peers.
    • dpd: on-demand retry-count 3 interval 20000ms: Dead Peer Detection mode and its retry and interval parameters.
    • auth: psk: Authentication method, such as a pre-shared key or certificate.
    • dhgrp: 14 5: Diffie-Hellman groups. At least one group must match the remote FortiGate or third-party peer.
    • fragmentation: enable: IKE message fragmentation used when an IKE message is too large and retransmission occurs. This does not refer to user-traffic fragmentation.
    • xauth: none: Whether XAuth is in use.
    • interface: wan: Physical or virtual originating interface configured under the IPsec Phase 1 interface.
  2. Check tunnel-interface addressing:

    • virtual-interface-addr: 192.240.240.1 -> 192.240.240.2 shows the local tunnel-interface address first and the remote address second.
    • This line is absent when no tunnel-interface IP addresses are configured.
    • When OSPF, BGP, or RIP must run across the VPN tunnel, this field must not be absent.
  3. For an ADVPN deployment, validate the role indicators:

    • auto-discovery-sender must be enabled on the hub.
    • auto-discovery-receiver must be enabled on the spoke.
  4. Examine the phase2s section carefully. It lists active Phase 2 parameters and features, for example:

VPN_ospf proto 0 src VPN_ospf_local:0 dst VPN_ospf_remote:0 dhgrp 14 5 replay keep-alive auto-negotiate route-new

Compare this information between peers to locate Phase 2 mismatches.

  1. Check the policy result:

    • policy: yes indicates that a policy exists for the VPN.
    • If the result is policy: no, add the appropriate firewall policy or policies. Without them, the tunnel will not come up.
  2. Starting with FortiOS 7.4.2, ESP packets can be encapsulated within TCP headers. Configure the transport under the Phase 1 interface as follows:

config vpn ipsec phase1-interface
edit VPN_ospf
set transport ?
tcp Use TCP transport for IKE.
udp Use UDP transport for IKE.
auto Use AUTO transport for IKE.
end

The diagnostic output can then include transport: tcp, meaning ESP is encapsulated in TCP headers. The value can also be udp or auto, where auto permits either transport.

  1. Also starting with FortiOS 7.4.2, QKD (quantum key distribution) can retrieve IPsec keys. This removes negotiation and simplifies IPsec key management. The diagnostic output displays QKD: no when QKD is not used and QKD: yes when it is configured or active. Configuration details are available in the FortiOS 7.4.2 Administration Guide: https://docs.fortinet.com/document/fortigate/7.4.2/administration-guide/775314/ipsec-key-retrieval-with-a-qkd-system-using-the-etsi-standardized-api-new

Verification

Run the following command again after correcting the configuration:

diagnose vpn ike config list

Confirm that status.admin is up, status.operational is up, and policy is yes. Compare both peers to ensure compatible IKE versions, modes, authentication, Diffie-Hellman groups, peer addresses, and Phase 2 settings. For FortiOS 7.4.2 or later, also verify the reported transport and QKD values when those functions are used.

Tags

No tags yet.

Community rating

/ 5 (0)

Discussion (0)

    No comments yet.