[Swan] Problem with libreswan Linux Libreswan 4.1-1 (netkey) on 5.8.0-38-generic

[Paul Wouters]

On Mon, 1 Feb 2021, Bo Osmann Erichsen wrote:

> I have an issue with Linux Libreswan 4.1-1 (netkey) on 5.8.0-38-generic (ubuntu 20.04) with a tunnel
> with remote end Fortigate 1500:
> 
> The tunnel (certificate based Ikev2 with xfrm/ipsec interface)  is established fine and traffic flows
> as expected.
> 
> After salifetime is reached – the connection goes down and will not get reestablished (no ipsec sa
> renegotiation or ike sa renegotiation). I suspect this state might give som input on the problem: 
> 
> "fgcon1" #5: encountered fatal error in state STATE_V2_REKEY_CHILD_I1

> I’ve tried setting ikelifetime and salifetime to be the same on the peer – but with no success.

Try setting it longer than the peer, so that the peer remains the
initiator. Eg try lifetime and ikelifetime of 24h

> Feb  1 10:00:08 ubuntu2004 pluto[43388]: |    Notify Message Type: v2N_NO_PROPOSAL_CHOSEN (0xe)

They do not like your proposal. This is weird because rekey does not
allow you to change the proposal anywway. So it should be the same
as the one you responded to originally? You can verify in the logs you
got the same Traffic Selectors and the same crypto parameters?

Perhaps there is a pfs mismatch, and the peer wants pfs=no ?

>      pfs=no

I would really try pfs=yes

>      aggressive=yes
>      ikev2=yes

Note ikev2 does not have aggressive mode, so the line aggressive= is
ignored.

>      salifetime = 30
>      ikelifetime = 30

Doesn't this mean 30 seconds ? At the very least do 8h

>      encapsulation=yes

You should really let the automatic encap detection do its work.

>      dpddelay=3
>      dpdtimeout=3
>      dpdaction=restart

You should not use restart, but hold. Also 3s is really short. It is
more reasonable to use 30s or 1m.

Paul