[Swan] NAT-T: Initial Main Mode exchange vs rekey Main Mode exchange

[Oleg Rosowiecki]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20220421/27f3b2da/attachment.htm>