<div dir="ltr">Dear Users/Libreswan Team,<div><br></div><div>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.</div><div><br></div><div>The sequence of events is this.</div><div><br></div><div>1. The tunnel gets established correctly, Libreswan creates state #1 (ISAKMP SA) and state #2 (IPSEC SA) objects.</div><div><br></div><div>2. A rekey event occurs within the configured rekey margin. State #3 (new ISAKMP SA) object gets initialized from state #1.</div><div><br></div><div>3. State #3 proceeds to perform the IKE exchange. The exchange succeeds (without XAUTH yet).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Oleg</div></div>