Troubleshooting Tip: IPsec tunnel troubleshooting (IKE negotiations debugging)
Description
This article describes how to troubleshoot IKE on an IPsec tunnel.
Scope
FortiGate.
Solution
Filter the IKE debugging log by using the following command:
diagnose vpn ike log filter name Tunnel_1
In versions before FortiOS v7.4.1, the command was:
diagnose vpn ike log-filter name Tunnel_1Â
The following are the other options for the IKE filter, as shown from the output of adding a '?' after the command:
diagnose vpn ike log filter ?
list Display the current filter.
clear Erase the current filter.
vd Index of virtual domain. -1 matches all.
name Phase1 name to filter by.
ifindex Index of the interface that IKE connection is negotiated over.
loc-addr4 IPv4 local gateway address range to filter by.
mloc-addr4 Multiple IPv4 local gateway address to filter by.
rem-addr4 IPv4 remote gateway address range to filter by.
mrem-addr4 Multiple IPv4 remote gateway address to filter by.
loc-addr6 IPv6 local gateway address range to filter by.
mloc-addr6 Multiple IPv6 local gateway address to filter by.
rem-addr6 IPv6 remote gateway address range to filter by.
mrem-addr6 Multiple IPv6 remote gateway addresses to filter by.
dst-port Destination port range to filter by.
negate Negate existing setting of the specified filter parameter.
Examples of IKE debug commands:
diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 x.x.x.x
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
Where the x.x.x.x are the Public IP addresses for the remote Client.
On v7.2 or below, the VPN filter must still be applied as follows:
diagnose vpn ike log-filter dst-addr4 x.x.x.x
Where the x.x.x.x are the Public IP addresses for the remote Client.
The 'diagnose debug application ike -1' command enables all available IKE debug levels, providing comprehensive debug output for the IPsec tunnel negotiation process. For more targeted troubleshooting, only the required IKE debug level can be enabled. The available debug levels are listed below:
ike error 0x01
ike config 0x02
ike negotiate 0x04
ike debug 0x08
ike keepalive 0x10
ike dpd 0x20
ike keys 0x40
ike packet 0x80
ike SLBC 0x100
Example output that shows that there is an issue with the VPN IKE negotiation:
ike 0: comes 192.168.175.153:500->192.168.175.152:500,ifindex=3....
ike 0: IKEv1 exchange=Identity Protection id=ceb2556bb6a76a83/69eea84d4ce9b6c8 len=108
ike 0: in CEB2556BB6A76A8369EEA84D4CE9B6C805100201000000000000006CCD04DA2FAF085808B8B045C1AE7D3E8A9BECB21CD179AACD8965B038D50A5A9713BCB6C53E5D18F6EE42EB77E8ADC0851783CBC676C7A93F30C0F9DCAC2E097A0E678A42D889777CAFC8DC0FC73C0E9F
ike 0:Tunnel_1:30: responder: main mode get 3rd message...
ike 0:Tunnel_1:30: dec CEB2556BB6A76A8369EEA84D4CE9B6C805100201000000000000006C7417465E8BE5E10828E160CB2ACED88EC9EC68E9C4B84E29743ED43E9723086CADD6EF04768A557744BADE51B4C19645E35B56519BB56CA1800DB16533C40AE802554C8E295986F716B7B3C288704D83
ike 0:Tunnel_1:30: parse error
ike 0:Tunnel_1:30: probable pre-shared secret mismatch
Note: In this example, the IPsec tunnel has a pre-shared key mismatch. From here, make the pre-shared key identical.
ike 0:Tunnel_1: local:192.168.175.152, remote:192.168.175.153
ike 0:Tunnel_1: cached as static-ddns.
ike 0: cache rebuild done
ike 0:46a575d716dbabec/0000000000000000:39: negotiation result
ike 0:46a575d716dbabec/0000000000000000:39: proposal id = 1:
ike 0:46a575d716dbabec/0000000000000000:39:Â Â protocol id = ISAKMP:
ike 0:46a575d716dbabec/0000000000000000:39:Â Â Â Â Â trans_id = KEY_IKE.
ike 0:46a575d716dbabec/0000000000000000:39:Â Â Â Â Â encapsulation = IKE/none
ike 0:46a575d716dbabec/0000000000000000:39:Â Â Â Â Â Â Â Â type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256
ike 0:46a575d716dbabec/0000000000000000:39:Â Â Â Â Â Â Â Â type=OAKLEY_HASH_ALG, val=SHA2_256.
ike 0:46a575d716dbabec/0000000000000000:39:Â Â Â Â Â Â Â Â type=AUTH_METHOD, val=PRESHARED_KEY.
ike 0:46a575d716dbabec/0000000000000000:39:Â Â Â Â Â Â Â Â type=OAKLEY_GROUP, val=MODP2048.
ike 0:46a575d716dbabec/0000000000000000:39: ISAKMP SA lifetime=86400
ike 0:46a575d716dbabec/0000000000000000:39: SA proposal chosen, matched gateway Tunnel_1Â
To stop and disable IKE debugging, run the following commands:
diagnose debug disable
diagnose debug resetÂ
Notes:
In this example, the IPsec tunnel has a 'no proposal chosen' error. From there, check the authentication and encryption of the IPsec tunnel_1 to ensure it is identical on both ends.
If no IKE debug is observed, see Troubleshooting Tip: Basic FortiGate Connectivity Diagnostics to verify whether FortiGate is dropping traffic.
By default, IKE debugs will only print output on the terminal for 30 minutes. If longer debugging periods are required, see Technical Tip: Changing debug duration.
Before running the IKE debug, 'diagnose vpn ike log filter clear' is always needed to initiate first as best practice because this command keeps the filter values even though the SSH PuTTY or FortiGate GUI CLI was closed. The values in 'diagnose vpn ike log filter' always inherit from another CLI.
Starting from FortiOS v7.6.3, it is possible to run IKE debugging directly from the GUI by navigating to VPN -> VPN Tunnels. 'Right-click' on the tunnel and select 'CLI diagnostics'. For more information, refer to Technical Tip: Collect IKE Debug Logs for IPsec VPN Directly from the GUI.
If the VPN tunnel interface binding is on a loopback or an internal interface other than the interface pointing towards the internet/wan where the IKE packets initially ingress on FortiGate, then an inbound firewall policy would be required to allow incoming IKE messages from the external/wan interface to the loopback interface. For further information, see Technical Tip: Best practice when IPSec VPN is bound to loopback interface.
FortiOS v8.0.1 and above enhances tunnel-down logging by providing clearer, more detailed log information to help administrators identify and troubleshoot IPsec tunnel failures faster. Refer to the doc for detailed information: Logging enhancements for tunnel down.
