Bug 1553406

Paul, is there by any chance a test for this? Or can it be triggered by some of DPD tests?

This should get triggered by regular DPD tests. send a few pings and idle the connection. It should not get torn down if the bug is resolved.

Use really fast dpd settings for testing

dpddelay=5
dpdtimeout=20
dpdaction=hold

After 20 seconds since last traffic over IPsec SA tunnel goes down without patch.

Hmm, does this bug actually affect libreswan-3.23-3.el7 (RHEL-7.5.0)? It looks like I just cannot reproduce the issue or I simply do not see it. 

I have this connection between server and client:

server
======
conn test
    left=<server>
    right=<client>
    authby=secret 
    auto=add
    dpddelay=5
    dpdtimeout=20
    dpdaction=restart
    ikev2=insist

client
======
conn test
    left=<client>
    right=<server>
    authby=secret
    auto=add
    ikev2=insist
    dpddelay=5
    dpdtimeout=20
    dpdaction=clear

Both client and server is running libreswan-3.23-3.el7. When client establish connection - it keeps working complete lifetime, it is not restarted, it just works even though it is idle (no ping or anything), connection numbers are the same whole time (#1 for ISAKMP, #2 for IPSEC). Both sides are exchanging liveliness messages every 5 seconds as expected:

Jun  7 14:53:49.350345: | inserting event EVENT_v2_LIVENESS, timeout in 5.000 seconds for #2

Any hints how to trigger issue? Is it really present in RHEL-7.5?

It is a bug only in 3.23 upstream, and the rhel build has libreswan-3.23-liveness-1553406.patch as of 3.23-4. So yes, 3.23-3 is broken for this.

(In reply to Paul Wouters from comment #8)
> It is a bug only in 3.23 upstream, and the rhel build has
> libreswan-3.23-liveness-1553406.patch as of 3.23-4. So yes, 3.23-3 is broken
> for this.

Yes, I can see that 3.23-3 is missing that patch. But I simply do not see any liveness issues. DPD test cases behave the same way with 3.23-3 and 3.23-4. With idle connection liveness checks on client are working smoothly with 3.23-3 every 5 seconds (dpddelay=5):

...
#4 liveness_check - last_liveness: 93824.217, now: 93824.223 parent #3
#4 liveness_check - peer <server> is missing - giving them some time to come back
#4 liveness_check - peer <server> is ok schedule new
Received an INFORMATIONAL response, updating st_last_liveness, no pending_liveness

...
#4 liveness_check - last_liveness: 93829.218, now: 93829.225 parent #3
#4 liveness_check - peer <server> is missing - giving them some time to come back
#4 liveness_check - peer <server> ok schedule new
Received an INFORMATIONAL response, updating st_last_liveness, no pending_liveness
...

With 3.23-4:

...
#2 liveness_check - last_liveness: 94461.566, now: 94461.621 parent #1
#2 liveness_check - peer <server> is missing - giving them some time to come back
#2 liveness_check - peer <server> is ok schedule new
Received an INFORMATIONAL response; updating liveness, no longer pending.
Received an INFORMATIONAL response, updating st_last_liveness, no pending_liveness
...
#2 liveness_check - last_liveness: 94466.567, now: 94466.623 parent #1
#2 liveness_check - peer <server> is missing - giving them some time to come back
#2 liveness_check - peer <server> is ok schedule new
Received an INFORMATIONAL response; updating liveness, no longer pending.
Received an INFORMATIONAL response, updating st_last_liveness, no pending_liveness
...

Clearly I not saying that there is not a bug in 3.23-3, what I am trying to say is that the actual issue addressed by patch is probably more complicated that the one described in this bugzilla. Hence I cannot verify it properly, I can only verify it SanilyOnly (ie. just checking that patch is applied and no regression pops up).

It is more complicated. We didn't do deep analysis why that change broke dpd, just noticed it did and reverted it on upstream. It might also be possible that only breaks if there are multiple IPsec SAs (leftsubnets=, rightsubnets=). Or only if passive dpd is used (one end is sending dpd, other end is just responding)

(In reply to Tuomo Soini from comment #10)
> It is more complicated. We didn't do deep analysis why that change broke
> dpd, just noticed it did and reverted it on upstream. It might also be
> possible that only breaks if there are multiple IPsec SAs (leftsubnets=,
> rightsubnets=). 

> Or only if passive dpd is used (one end is sending dpd,
> other end is just responding)

That's it! Finally I can clearly see it. Thanks a lot!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3174