FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
acvaldez
Staff
Staff
Article Id 190052

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:

 

diag vpn ike log-filter name Tunnel_1

For later firmwares, the command "log-filter" has been changed to "log filter"

diag vpn ike log filter name Tunnel_1

 

Here are the other options for the IKE filter:

 

list             <- Display the current filter.
clear           <- Erase the current filter.
name             <- Phase1 name to filter by.
src-addr4     <- IPv4 source address range to filter by.
msrc-addr4    <- Multiple IPv4 source address to filter by.
dst-addr4      <- IPv4 destination address range to filter by.
mdst-addr4    <- Multiple IPv4 destination address to filter by.
src-addr6      <- IPv6 source address range to filter by.
msrc-addr6    <- Multiple IPv6 source address to filter by.
dst-addr6     <- IPv6 destination address range to filter by.
mdst-addr6    <- Multiple IPv6 destination addresses to filter by.
src-port       <- Source port range to filter by.
dst-port      <- Destination port range to filter by.
vd                <- Index of virtual domain. -1 matches all.
interface     <- Interface that IKE connection is negotiated over.
negate          <- Negate the specified filter parameter.

 

diag debug app ike -1  <- In order to do the VPN debug.

diag debug console timestamp enable <- In order to cross check with VPN events.
diag debug enable <- In order to display the debug output.

 

Note:

Starting from FortiOS 7.4.1, the log filter commands have been changed to 'diagnose vpn ike log filter'.

 

Example below:

 

list             <- Display the current filter.
clear           <- Erase the current filter.
name             <- Pase1 name to filter by.
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.
mdst-addr6    <- Multiple IPv6 destination addresses to filter by.
dst-port      <- Destination port range to filter by.
vd                <- Index of virtual domain. -1 matches all.
interface     <- Interface that IKE connection is negotiated over.
negate          <- Negate the specified filter parameter.

 

Sample output that shows that there is an issue on 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 sample, 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

-------------------------------------------------------------------------------------------------------------------------------------

 

Note:

In this example, the IPsec tunnel has no proposal chosen error. From there, check the authentication and encryption of the IPsec tunnel_1 to make sure that it is identical on both ends.