[Swan-dev] Bug libreswan-5.0rc2

[Andrew Cagney]

On Wed, 20 Mar 2024 at 06:42, Armen Dilanyan <ad at 2ip.am> wrote:
>
> The "discarding" and "dropping" log lines? These aren't really
> errors, or were you not seeing them before?
>
>
> Previously, when RemoteAccess_user1 connected, the event logs showed the ID of RemoteAccess_user1
>
> Feb 05 15:02:15 hostname pluto[8882]: "RemoteAccess_user1"[1] 1.1.1.1 #2: discarding packet received during asynchronous work (DNS or crypto) in STATE_V2_PARENT_R1

> Now, when RemoteAccess_user2 connects, the ID in the event logs is not RemoteAccess_user2, but the ID of the first one in the configuration file is Mikrotik_Mikrotik1.

> Mar 20 15:23:21 ngfw pluto[15469]: "Mikrotik_Mikrotik1/1x0"[121] 2.2.2.2 #394: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
> Mar 20 15:23:21 ngfw pluto[15469]: "Mikrotik_Mikrotik1/1x0"[121] 2.2.2.2 #394: processed IKE_SA_INIT request from 2.2.2.2:UDP/500 {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
...
> Mar 20 15:23:24 ngfw pluto[15469]: "Mikrotik_Mikrotik1/1x0"[121] 2.2.2.2 #394: switched to "RemoteAccess_user2"[12] 2.2.2.2

The code's working, but I can understand your surprise.

First the disclaimer:

- because the IKE_SA_INIT contains no identifying information,  any
one of the connections that has matching addresses is picked
- then during IKE_AUTH, when the ID and subnet information is
available, the connection is switched to one that fully matches, or
the connection is rejected

The key thing is that when two connections match based on address, the
choice pluto makes isn't documented (you should assume either) and as
we see here, it can change.

And what changed:

In v4, given "con" which turns into con/1x1 ..., con/1x9, which was
initiated was determined by a strange combination of how addconn fed
connections to pluto, and pluto then processed them (in effect, a list
was reversed three times).  The result was con/1x1 initiated the
IKE_SA but then con/1x9 was negotiated during IKE_AUTH as the first
child.

In v5, this is all handled within pluto.  And as part of this, things
were fixed so that con/1x1 initiates con/1x1 as the first Child SA
(ya).  But it does also re-order other stuff.

You could try re-ordering your config file, but I didn't say that.

Andrew