Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 26 subscribers
  • Views 467 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSEC Tunnels Not Cleanly Renegotiated/Re-initated After Link Flap

djdrastic

Hi just checking if someone has seen this before.

We have a client that that has a satellite office that is connected via wireless last mile and runs ipsec tunnels back to their HQ. They have quite a lot of subnets at the hq side that they need to connect to even with summarized addressing it's around 4 x /20 summarized cidrs that they advertise over the tunnel.

Sometimes due to weather conditions they will get some real nasty link flaps that causes the ipsec tunnels to go down . What we've found is at random link flaps some of the subnets will not be negotiated properly (indicated via orange status) on ipsec  connection detail.Resetting the tunnel brings back everything up clean (aka green) but I'm looking for a permanent solution because we get a flood of emails in the morning about systems being down.

DPD is set as Disconnect at HQ side and Re-initiate at the Branch.



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember

    Hi , Thanks for reaching out to Sophos Community.

    Can you check with the Key-life defined in the policy on each device? Please share the snapshot of the Policy configuration on each end as well.

    You can also check in the strongswan log file available in /log/strongswan.log. ( Take SSH , Option 5 > Option 3 Advanced Shell) for the specific timestamp when the issue had occurred. 

  • 0 in reply to FormerMember

    Will take some screenshots but looking at that log at around that time seeing the following error messages so something is amiss.

    2021-06-23 19:16:04 09[DMN] [GARNER-LOGGING] (child_alert) ALERT: received IKE message with invalid SPI (E576BD33) from other side
    2021-06-23 19:16:34 17[DMN] [GARNER-LOGGING] (child_alert) ALERT: received IKE message with invalid SPI (E576BD33) from other side
    2021-06-23 19:16:34 22[DMN] [GARNER-LOGGING] (child_alert) ALERT: received IKE message with invalid SPI (E576BD33) from other side
    2021-06-23 19:16:34 09[DMN] [GARNER-LOGGING] (child_alert) ALERT: received IKE message with invalid SPI (E576BD33) from other side

  • FormerMember
    0 FormerMember in reply to djdrastic

    It could be with the re-keying time. Can you verify whether is that identical for Phase 1 and 2 in the ipsec policy on both ends? 

Reply Children
No Data