I noticed a regression in test ikev2-ike-rekey-03. I was hunting an issue Tuomo found. While trouble shooting it I noticed this regression.
http://testing.libreswan.org/results/testing/v3.22-1493-g346d358-master/ikev2-ike-rekey-03/OUTPUT/ http://testing.libreswan.org/results/testing/v3.22-1500-g2efd341-master/ikev2-ike-rekey-03/ for now the workaround seems to be "uniqueids=no" which is good idea with IPsec SAs sharing IKE SA. It seems one of the IPsec SAs, there are 3 IPsec SA and one IKE SA, get quietly deleted when rekeyig IKE SA. Regression is between 346d358 2efd341. I suspect 9bd57bb "pluto: Upon IKE SA establishing, check if any connections or states need cleaning" there is a long history of uniqueids and initial-contact in libreswan. my 00.2c comment "uniqueids=no" on peer-to-peer makes sense to me. Here is a background read, the old discussion about initial-contact/uniqueid between peer-to-peer with multiple Child SAs and DPDs enabled. It could be challenge and cause race conditions. https://www.ietf.org/mail-archive/web/ipsec/current/msg08307.html _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
