IPsec VPN keeps down after a Direct connect with AWS flaps

[Angeles]

I have a serie of tunnels IPsec VPN stablished from the Fortigate FortiGate-200F (On-prem) toward AWS console over a Direct connect, during a maintenance window of my provider, the Direct connect had a slight flapping and it recovered , but all tunnels kept down as if they could not negotiate the IKE singnaling.  After throubleshooting the virtual interface had to be reset to reestablish the tunnels. My doubt is why the tunnels could not be restablished by themself. The current version is v7.0.14

[salemneaz]

Would you please check the Logs and see what error was there. If the tunnel is not passing any data and once it is down it stays down, we have to manually bring it back up. But if this is happening frequently then you need to run further debug and find out.

[Angeles]

These messages were capture with a debug during the IPsec  VPN failure and they repeated over and over again

2024-07-31 00:53:49.480270 ike 0:vpn-aws-prd-tg1:1547466: sent IKE msg (RETRANSMIT_SA_INIT): 10.115.14.249:500->192.168.1.0:500, len=272, vrf=0, id=0a
8ed3721f68ad64/0000000000000000
2024-07-31 00:53:50.490434 ike 0:vpn1:vpn1: IPsec SA connect 0 10.100.33.200->192.168.22.0:0
2024-07-31 00:53:50.490454 ike 0:vpn1:vpn1: using existing connection
2024-07-31 00:53:50.490466 ike 0:vpn1:vpn1: config found
2024-07-31 00:53:50.490472 ike 0:vpn1:vpn1: request is on the queue
2024-07-31 00:53:55.500435 ike 0:vpn1:vpn1: IPsec SA connect 0 10.100.33.200->192.168.22.0:0
2024-07-31 00:53:55.500458 ike 0:vpn1:vpn1: using existing connection
2024-07-31 00:53:55.500469 ike 0:vpn1:vpn1: config found
2024-07-31 00:53:55.500475 ike 0:vpn1:vpn1: request is on the queue
2024-07-31 00:54:00.510435 ike 0:vpn1:vpn1: IPsec SA connect 0 10.100.33.200->192.168.22.0:0
2024-07-31 00:54:00.510458 ike 0:vpn1:vpn1: using existing connection
2024-07-31 00:54:00.510470 ike 0:vpn1:vpn1: config found
2024-07-31 00:54:00.510476 ike 0:vpn1:vpn1: request is on the queue
2024-07-31 00:54:01.471149 ike 0:vpn1:vpn1:1547466: out 0A8ED3721F68AD6400000000000000002120220800000000000001102200002800000024010100030300000C
01000014800E0100030000080200000600000008040000142800006800140000CCABD2E75E1EE168386E6FA84C419A4238DF6E0DBCE509AAF249AA424481CD53E9075AAD23240FE947E132
1B01F289712722FDEF9E19FBDC14F06735D0835FD2AB6983601EFD177F47FE9B26DBE5E7102290000248CF21FB56750B424104BD23188C27D8B7D5B
11BC2F8ACCFF7369D9A4D8B113612900001C00004004E22DECBA57C04E574158C732A6ED4C721BD562BA2900001C000040051E61229AD8B402E185725A6EB261F32DD34AFA590000000800
00402E
2024-07-31 00:54:01.471187 ike 0:vpn1:vpn1::1547466: sent IKE msg (RETRANSMIT_SA_INIT): 10.100.33.200:500->192.168.22.0:500, len=272, vrf=0, id=0a
8ed3721f68ad64/0000000000000000 

[Shashwati]

Hello

Log showed there was retransmission from 10.115.14.249:500->192.168.1.0:500 for SA negotiation 

No reply was showing from 192.168.1.0 

If this was AWS IP then there was no reply from AWS

[mmanrique]

Hello,

Please make sure you have Autoconnect enable in both Fortigates (phase 2).

also, are you using a dynamic routing protocol like BGP? it looks like a routing issue.

You might want to debug flow this traffic:

#diag deb reset

#diag deb flow filter clear

#diag deb sh fun en

#diag deb flo filter port 500

#diag deb flow trace start 500

#diag deb en

Try running that debug when the tunnels are down.