IPsec site-to-site problem

[DongPham]

I have an IPsec VPN connection between FG100D and SSG. Firmware of FG100D is 6.2.10. Recently the VPN connection went down and couldn't reconnect. I capture the IKE logs as below:

ike 0:To_BYHN: schedule auto-negotiate
ike 0:To_BYHN:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:0
ike 0:To_BYHN:To_BYHN: config found
ike 0:To_BYHN: created connection: 0x149b2d00 51 222.252.97.229->124.158.3.197:500.
ike 0:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:500 negotiating
ike 0:To_BYHN: no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation
ike 0:To_BYHN:745434: initiator: main mode is sending 1st message...
ike 0:To_BYHN:745434: cookie 137dd2ae1f9fb3b2/0000000000000000
ike 0:To_BYHN:745434: out 137DD2AE1F9FB3B200000000000000000110020000000000000001240D00003C000000010000000100000030010100010000002801010000800B0001000C00040001518080010007800E00808003000180020002800400020D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE00000000
ike 0:To_BYHN:745434: sent IKE msg (ident_i1send): 222.252.97.229:500->124.158.3.197:500, len=292, id=137dd2ae1f9fb3b2/0000000000000000
ike 0: cache rebuild done
ike 0: cache rebuild done
ike 0:To SNA: auto-negotiate connection
ike 0:To SNA: created connection: 0x149f2710 51 222.252.97.229->14.189.138.166:500.
ike 0:To_BYHN:745434: out 137DD2AE1F9FB3B200000000000000000110020000000000000001240D00003C000000010000000100000030010100010000002801010000800B0001000C00040001518080010007800E00808003000180020002800400020D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE00000000
ike 0:To_BYHN:745434: sent IKE msg (P1_RETRANSMIT): 222.252.97.229:500->124.158.3.197:500, len=292, id=137dd2ae1f9fb3b2/0000000000000000
ike 0:To_BYHN:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:0
ike 0:To_BYHN:To_BYHN: using existing connection
ike 0:To_BYHN:To_BYHN: config found
ike 0:To_BYHN: request is on the queue
ike 0:To_BYHN:745434: out 137DD2AE1F9FB3B200000000000000000110020000000000000001240D00003C000000010000000100000030010100010000002801010000800B0001000C00040001518080010007800E00808003000180020002800400020D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE00000000
ike 0:To_BYHN:745434: sent IKE msg (P1_RETRANSMIT): 222.252.97.229:500->124.158.3.197:500, len=292, id=137dd2ae1f9fb3b2/0000000000000000
ike 0:To_BYHN:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:0
ike 0:To_BYHN:To_BYHN: using existing connection
ike 0:To_BYHN:To_BYHN: config found
ike 0:To_BYHN: request is on the queue
ike 0:To_BYHN:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:0
ike 0:To_BYHN:To_BYHN: using existing connection
ike 0:To_BYHN:To_BYHN: config found
ike 0:To_BYHN: request is on the queue
ike 0:To_BYHN:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:0
ike 0:To_BYHN:To_BYHN: using existing connection
ike 0:To_BYHN:To_BYHN: config found
ike 0:To_BYHN: request is on the queue
ike 0:To_BYHN:745434: out 137DD2AE1F9FB3B200000000000000000110020000000000000001240D00003C000000010000000100000030010100010000002801010000800B0001000C00040001518080010007800E00808003000180020002800400020D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE00000000
ike 0:To_BYHN:745434: sent IKE msg (P1_RETRANSMIT): 222.252.97.229:500->124.158.3.197:500, len=292, id=137dd2ae1f9fb3b2/0000000000000000
ike 0:To_BYHN:To_BYHN: IPsec SA connect 51 222.252.97.229->124.158.3.197:0
ike 0:To_BYHN:To_BYHN: using existing connection
ike 0:To_BYHN:To_BYHN: config found
ike 0:To_BYHN: request is on the queue
ike 0:To_BYHN:745434: negotiation timeout, deleting
ike 0:To_BYHN: connection expiring due to phase1 down
ike 0:To_BYHN: deleting
ike 0:To_BYHN: deleted

Please help me resolve it.

[fricci_FTNT]

Hi @DongPham ,

From the logs it seems that the FortiGate (222.252.97.229) is initiator, it tries to send requests to renegotiate the tunnel but no response are received from 124.158.3.197, then the negotiation goes in timeout:

ike 0:To_BYHN:745434: negotiation timeout, deleting
ike 0:To_BYHN: connection expiring due to phase1 down

It seems that something happened on the other peer side (or in the path between the remote peer and the FortiGate). To resolve it, you may need to restart the IPSEC tunnel on the remote peeror check the path between them  (and if it is not enough, restart it on the FortiGate side too).

Hope this helps.

Best regards,

[DongPham]

124.158.3.197 is the SSG firewall and sometimes the VPN goes down. At that time I had to restart the FG100D and the VPN was restored automatically. But I can't reboot at any time when the VPN is down. I have updated Firmware 6.2.15 to monitor. VPN is up now.

[vbandha · Accepted solution]

@DongPham Instead of restarting Fortigate, you can try disabling the tunnel interface and then enabling it back again if issue happens again. 
Also please check the Dead Peer detection setting on both sides. Make sure it is set to On Idle. 

[DongPham]

@vbandha Thanks. It is already set On Idle. If the VPN down again, I will try your solution.

[hbac]

Hi @DongPham.,

(P1_RETRANSMIT): 222.252.97.229:500->124.158.3.197:500 means 124.158.3.197 is not responding to the negotiation. You need to run debugs on 124.158.3.197 to see why. 

Regards, 

[Nchandan]

Based on the logs, it seems that the FortiGate is initiating the connection, but the remote FortiGate is not responding. To check if the remote end is responding, capture the packet at port 500 with the IP of the remote FortiGate on both firewalls. This will help determine if the packets are reaching the remote end or if they are being blocked by the ISP. You can also verify if the packets are being dropped or blocked by the ISP level.

[sw2090]

Does one side have a ddns as remote gw? In that case you will be hit by a bug in FortiOS IPSec stack that causes the ipsec to not update the remote gw ip even if the ddns itself changes.