Upgrade from 2.1.5 - 2.2.2 IPSEC rekey issue

We have a production environment running 2 PFS servers with failover via CARP etc as VM's on VMWare. This weekend we had scheduled downtime to upgrade our firewalls from 2.1.5 - 2.2.2. I took a snapshot and upgraded, ran into a bug where the firewalls did not reboot automatically after upgrading but was able to work around that (there is an option to run a command such as reboot from the GUI cmd line interface) and everything seemed fine.

Unfortunatly after 8h our IPSEC (3DES SHA1) vpn dropped. We initially thought this was a one off so after disabling/restablishing the tunnel and bringing it back up left it again. Unfortunatly again after 8h it drops. Our lifetime on P1 and P2 is 28800 seconds (8h) so we imagine its related to this.

We have rolled the snapshots back to 2.1.5 since we have to have the IPSEC tunnel stable in a production environment.

There are some issues we are working on yet for IPsec, and rekeying in certain cases is an issue, especially when the other end is an ASA.

Sometimes disabling rekey on your side helps. Other times, moving the IKEv2 helps, and some other cases yet don't have a good solution in a -RELEASE version but may be improved in 2.2.3 pre-release snapshots.

We have a production environment running 2 PFS servers with failover via CARP etc as VM's on VMWare. This weekend we had scheduled downtime to upgrade our firewalls from 2.1.5 - 2.2.2. I took a snapshot and upgraded, ran into a bug where the firewalls did not reboot automatically after upgrading but was able to work around that (there is an option to run a command such as reboot from the GUI cmd line interface) and everything seemed fine.

Unfortunatly after 8h our IPSEC (3DES SHA1) vpn dropped. We initially thought this was a one off so after disabling/restablishing the tunnel and bringing it back up left it again. Unfortunatly again after 8h it drops. Our lifetime on P1 and P2 is 28800 seconds (8h) so we imagine its related to this.

We have rolled the snapshots back to 2.1.5 since we have to have the IPSEC tunnel stable in a production environment.

2.2.1 and earlier have strongswan 5.2.x, where specifying the reqid works around a rekeying problem. 2.2.2 and 2.2.3 snapshots have strongswan 5.3.0, where the problem that required specifying the reqid is gone, and with multiple P2s doing so can cause you to hit a race condition in strongswan where it duplicates reqids, which breaks multi-P2 where you hit it.