Upgrade from 2.1.5 - 2.2.2 IPSEC rekey issue
-
Hi,
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.
It seems similar to the issues on these 2 posts:
https://forum.pfsense.org/index.php?topic=92716.0
https://forum.pfsense.org/index.php?topic=91020.0Im not sure what we can do to stabalise the VPN tunnel. Is this a confirmed issue in 2.2.1/2.2.2? We are a gold subscriber if that means anything.
Any help would be appreciated.
-
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.
-
Hi jimp!
Thanks for letting me know, I will retry when 2.2.3 is released and post back when I have done that.
Pete
-
Hi,
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.
It seems similar to the issues on these 2 posts:
https://forum.pfsense.org/index.php?topic=92716.0
https://forum.pfsense.org/index.php?topic=91020.0Im not sure what we can do to stabalise the VPN tunnel. Is this a confirmed issue in 2.2.1/2.2.2? We are a gold subscriber if that means anything.
Any help would be appreciated.
I have had no trouble in Ipsec with my 2.2.1 production boxes. 2.2.2 upgrade broke Ipsec for me with 2 P2 entries. when i rolled back to 2.2.1 Ipsec again works without trouble. just FYI.
-
Thanks for the info, I never used 2.2.1 so havent tested that scenario.
Im going to hold on to 2.2.3 and retest it all :)Pete
-
I have had no trouble in Ipsec with my 2.2.1 production boxes. 2.2.2 upgrade broke Ipsec for me with 2 P2 entries. when i rolled back to 2.2.1 Ipsec again works without trouble. just FYI.
That's almost certainly fixed by the reqid change here:
https://github.com/pfsense/pfsense/commit/afd0c1f2c9c46eaa8e496e98bea8a8e0887d504f2.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.
