[Swan] Lost IKEv1 connectivity after libreswan upgrade

[Paul Wouters]

On Wed, 24 Nov 2021, Mirsad Goran Todorovac wrote:

> Subject: Re: [Swan] Lost IKEv1 connectivity after libreswan upgrade

> It seems that IPSEC is established, and a transport connection:
>
> Nov 24 15:16:18.322599: | pstats #14 ikev1.ipsec established
> Nov 24 15:16:18.322609: | NAT-T: encaps is 'auto'
> Nov 24 15:16:18.322617: "L2TP-PSK-noNAT"[7] 193.198.186.218 #14: 
> STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0xbd9d07f4 
> <0x935a0ca5 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=none DPD

On the server side at least. But the last packet sent by the server
still has to be accepted by the client.

> but then, after receiving first encrypted packet, pluto spuriously decides to 
> delete, "down" the connection and "unroute" it:
>
> Nov 24 15:16:53.359857: | State DB: found IKEv1 state #13 in MAIN_R3 
> (find_v1_info_state)

R3 is not yet fully established.

> Nov 24 15:16:53.360046: | ***parse ISAKMP Hash Payload:
> Nov 24 15:16:53.360056: |    next payload type: ISAKMP_NEXT_D (0xc)

This is a Delete request. The client is unhappy with something and
deleting the connection. If this is due to an upgrade, it could be the
new defaults for our algorithms aren't matching the old defaults?
Although we havent changed IKEv1 defaults in a very long time.

> I seem to be stuck here, I don't know how to debug connection.

The client should have a log message about why it decided to hang up?

Paul