Dear Users/Libreswan Team, I'm having issues with rekeying tunnels for a road-warrior client that is behind NAT. The client is Libreswan, the other end is a Fortigate device. I'm trying to troubleshoot. The relevant configuration is this: IKEv1, PSK, XAUTH, ModeCfg, IP assignment from the ModeCfg server (i.e. the remote end), IKE SA rekey set to 15 minutes on both ends, IPSEC SA rekey set to 1h on both ends.
The sequence of events is this. 1. The tunnel gets established correctly, Libreswan creates state #1 (ISAKMP SA) and state #2 (IPSEC SA) objects. 2. A rekey event occurs within the configured rekey margin. State #3 (new ISAKMP SA) object gets initialized from state #1. 3. State #3 proceeds to perform the IKE exchange. The exchange succeeds (without XAUTH yet). At this stage, the other end concludes that it's a duplicate tunnel from the same host/client and deletes its SAs (corresponding to state #2 and state #1). It sends the delete notifications to Libreswan and Libreswan deletes its state #1 and state #2 objects while state #3 is in progress. This ultimately affects state #3 as well. The problem is probably with the other end of the tunnel being unable to tell between the initial Main Mode negotiation and the one that's initiated during rekey. So I'd like to learn how this is *supposed* to work (with or without NAT-T). The initiator initiates a rekey sequence, performs the IKE exchange with the remote peer to establish a new ISAKMP SA while the previous one still works. How should the remote peer tell that this is a rekey event and react accordingly? Thanks, Oleg
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
