| Description |
This article describes how to use 'diagnose vpn ike config list' to troubleshoot IPSec VPN issue.
Sometimes, the VPN tunnel is not coming up because of configuration error/mismatched parameter(s) between the 2 VPN peers or because the connection is being blocked by Firewall policy. |
| Scope |
FortiGate v6.4 FortiGate v7.0 FortiGate v7.2. |
| Solution |
If the IPSec VPN tunnel refused to come up, quickly use the command: 'diagnose vpn ike config list' to check if there is a mismatch/error in the configuration. If both ends are FortiGate, execute the cmd on both and do a comparison.
diagnose vpn ike config list vd: root/0
Explanation:
vd: root/0 <- The VDOM where this VPN (VPN_ospf) is configured and the ID of the VDOM. In a multi-VDOM environment, it can show if a wrong VDOM is configured.
name: VPN_ospf <- Name of the VPN (phase1 name).
version: 1 <- The tunnel IKE version (if there is IKE version mismatch between the 2 ends, it can be easily seen).
status.admin: up<- Tells if VPN interface is up or down.
status.operational: up <- This will show down if the VPN is down.
type: static <- The type of VPN configured. It will tell if the right/intended VPN type (static or dynamic) is configured.
local: 10.xxx.17.23 <- The source of the VPN tunnel on this FortiGate.
remote: 10.xxx.16.190 <- The destination/termination of this VPN tunnel or IP on the remote peer.
mode: main <- Informs the user whether main mode or aggressive mode are running.
dpd: on-demand retry-count 3 interval 20000ms <- The type of DPD configured/enabled on this VPN tunnel with DPD parameters.
auth: psk <- Type of authentication deployed: pre-shared key, certificate, etc.
dhgrp: 14 5 <- Diffie-Hellman group used. At least one of these parameter(s) must be the same as the one on the remote FortiGate (or third-party device).
fragmentation: enable <- This is the fragmentation of IKE packet (message) when re-transmission occurred because the IKE message is too large; it's not fragmentation of user traffic.
xauth: none <- If xauth is used or not.
interface: wan <- The physical/virtual interface on which the VPN tunnel originated from or interface configured under ipsec phase1-interface.
virtual-interface-addr: 192.240.240.1 -> 192.240.240.2 <- If an IP address is configured on the tunnel interface, the detail is present here. If the tunnel is without IP, this parameter will NOT show at all. The first IP is local, and the second or one pointed to is remote. In a case where it is necessary to run other dynamic routing protocols (OSPF, BGP, RIP) on the VPN tunnel, this must NOT be absent.
auto-discovery-sender: disable <- In the ADVPN environment, this (sender) needs to be enabled on the HUB.
auto-discovery-receiver: disable <- In the ADVPN environment, this (receiver) needs to be enabled on the SPOKE.
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 <- This shows phase2 features/parameters that is running, plus their detail. If there is phase2 mismatch issue, this section will be helpful and need to be carefully checked.
policy: yes <- This tells if having policy in place for this VPN or not (very important indicator). Example: If there is policy: no, the tunnel will not come UP and it will be necessary to add appropriate Firewall Policy(ies) to resolve the issue.
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
Also, starting from FortiOS 7.4.2, QKD (quantum key distribution) can be used for IPsec key retrieval: This eliminates negotiation, simplifies the process, and enhances efficiency in IPsec key management. QKD configuration details can be found here.
With the above changes, the 'diagnose vpn ike config list' output will look like this:
transport: tcp <- This means the ESP is encapsulated in TCP headers, it can also be UDP or auto (either). QKD: no <- This means QKD is not in use. It will be 'yes' if in use or configured. |
