IPSEC - Timeouts - between FG201F Cluster 7.2.13 and SFOS 22.0.0 GA-Build411

on the phase2 do you have auto-negotiate and keepalive enabled ? if not, try enabling them.

on phase1 do you use dpd ?

Hi,

Sorry for the late reply, but we had a holiday here in Germany. I'll try to get the necessary information in the next few days.

We try the setting “keepalive enable”, but same issue...

Hi @Cordial,

How did you confirm that re-keying is causing the problem ? 

Refer follow the steps to identify the problem:

Assuming,  that destination IP address is hosted behind Sophos

---

PuTTY1:

Step 1: 

# get sys ha status
# diagnose sys ha history read
# diagnose sys link-monitor status
# diagnose sys sdwan health-check status

Step 2: Routing Lookup for Source and Destination Private IPs

# get router info routing detail <destination>
# get router info routing detail <source>
# get router info routing detail <Public IP Remote-GW>

Step 3: Verify VPN Status (UP or DOWN)

# get vpn ipsec tunnel summary | grep -f <tunnel_name>
# diagnose vpn ike gateway list name <tunnel_name>
# diagnose vpn tunnel list name <tunnel_name>

Step 4: Collect Packet Capture (Sniffer)
- For private communication:

# diagnose sniffer packet any “host x.x.x.x and host y.y.y.y and icmp” 4 0 a

(replace `x.x.x.x` with the source IP and `y.y.y.y` with the destination IP)

- For public ESP packet communication:

# diagnose sniffer packet any “host x.x.x.x” 4 0 a

(replace `x.x.x.x` with the remote gateway's public IP)

**If the tunnel is down, proceed with Step 5. Otherwise, move to Step 6.**

Step 5: Collect IKE Debug Logs (if tunnel is down)

diagnose debug reset
diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 x.x.x.x  # replace with remote gateway IP
diagnose debug console timestamp enabled
diagnose debug app ike -1
diagnose debug enable

Wait 5-10 seconds, then disable debug logs:

diagnose debug disable

Step 6: If the tunnel is up but reaching a specific destination fails, collect flow debug logs

diagnose debug reset
diagnose debug flow show console enable
diagnose debug flow show function-name enable
diagnose debug flow show iprope enable
diagnose debug flow filter addr x.x.x.x  <-----replace with destination IP
diagnose debug flow trace start 10000
diagnose debug enable

Wait 5-10 seconds, then disable debug logs:

diagnose debug disable

​
If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.

Thanks
Mayur Padma

We tried 5400, then 3600, and now 1800, and it was always just before renewal p2

We already looked into this recently and determined that it happens during rekeying.
 
Our firmware still had the SA even though no data was being transmitted, and Sophos's status was unknown at the time.
When the rekeying took place, data transmission resumed.
That's why we reduced the SA lifetime to 30 minutes so we could track this more effectively.

This sounds very much like a Phase 2 rekey mismatch or DPD issue between Sophos and FortiGate. I’d recommend checking PFS settings, Phase 2 lifetime values, and disabling/reducing DPD temporarily for testing. Also verify both sides use identical encryption/hash settings and MTU/MSS values. We had a similar issue once that was resolved by matching Phase 2 lifetimes exactly on both peers.

Today we try phase 1 and phase 2 diffrent timezones (sophos initiator and higher rekeytime for phase 1 and phase 2) - nothing helps - we try another MTU values - nothing helps - we try to set NPU-Offloading - nothing helps -  next step is to contact sophos support for more debug - today i had 3 supporter with very high experience in one meeting - we found no solution….