Does not recover gracefully from suspend on MacOS

[ryanakca]

OpenIKED does not recover gracefully from a system suspend on macos. I find myself having to stop and restart the service to get the connection back in a working state.

After suspending from some time and resuming, I see the following output:

spi=0x6ce28cd71c0d14e9: send INFORMATIONAL req 2 peer HADES:4500 local 192.168.1.102:4500, 61 bytes, NAT-T
spi=0x471b1b4c159a673f: send INFORMATIONAL req 2 peer EOS:4500 local 192.168.1.102:4500, 61 bytes, NAT-T
spi=0x6ce28cd71c0d14e9: retransmit 1 INFORMATIONAL req 2 peer HADES:4500 local 192.168.1.102:4500
spi=0x471b1b4c159a673f: retransmit 1 INFORMATIONAL req 2 peer EOS:4500 local 192.168.1.102:4500
spi=0x6ce28cd71c0d14e9: retransmit 2 INFORMATIONAL req 2 peer HADES:4500 local 192.168.1.102:4500
spi=0x471b1b4c159a673f: retransmit 2 INFORMATIONAL req 2 peer EOS:4500 local 192.168.1.102:4500
spi=0x6ce28cd71c0d14e9: retransmit 3 INFORMATIONAL req 2 peer HADES:4500 local 192.168.1.102:4500
spi=0x471b1b4c159a673f: retransmit 3 INFORMATIONAL req 2 peer EOS:4500 local 192.168.1.102:4500
spi=0x6ce28cd71c0d14e9: retransmit 4 INFORMATIONAL req 2 peer HADES:4500 local 192.168.1.102:4500
spi=0x471b1b4c159a673f: retransmit 4 INFORMATIONAL req 2 peer EOS:4500 local 192.168.1.102:4500
spi=0x471b1b4c159a673f: retransmit 5 INFORMATIONAL req 2 peer EOS:4500 local 192.168.1.102:4500
spi=0x6ce28cd71c0d14e9: retransmit 5 INFORMATIONAL req 2 peer HADES:4500 local 192.168.1.102:4500
spi=0x6ce28cd71c0d14e9: sa_free: retransmit limit reached
spi=0x471b1b4c159a673f: sa_free: retransmit limit reached
ikev2_init_ike_sa: initiating "hades"
spi=0x0470bdf2af6158ec: send IKE_SA_INIT req 0 peer EOS:500 local 0.0.0.0:500, 502 bytes
ikev2_init_ike_sa: initiating "eos"
spi=0x0f3d60938e6d52e5: send IKE_SA_INIT req 0 peer HADES:500 local 0.0.0.0:500, 502 bytes
spi=0x0470bdf2af6158ec: recv IKE_SA_INIT res 0 peer EOS:500 local 192.168.1.102:500, 239 bytes, policy 'hades'
spi=0x0470bdf2af6158ec: send IKE_AUTH req 1 peer EOS:4500 local 192.168.1.102:4500, 1459 bytes, NAT-T
spi=0x0f3d60938e6d52e5: recv IKE_SA_INIT res 0 peer HADES:500 local 192.168.1.102:500, 239 bytes, policy 'eos'
spi=0x0f3d60938e6d52e5: send IKE_AUTH req 1 peer HADES:4500 local 192.168.1.102:4500, 1459 bytes, NAT-T
spi=0x0470bdf2af6158ec: recv IKE_AUTH res 1 peer EOS:4500 local 192.168.1.102:4500, 1528 bytes, policy 'hades'
spi=0x0470bdf2af6158ec: ikev2_ike_auth_recv: obtained lease: 10.0.1.102
spi=0x0470bdf2af6158ec: ikev2_childsa_enable: loaded SPIs: 0x4fd094d8, 0xd096ed95 (enc aes-128-gcm)
spi=0x0470bdf2af6158ec: ikev2_childsa_enable: loaded flows: ESP-10.0.1.102/32=10.0.1.0/24(0)
spi=0x0470bdf2af6158ec: established peer EOS:4500[ASN1_DN//CN=HADES] local 192.168.1.102:4500[ASN1_DN//CN=DEMETER] policy 'hades' as initiator (enc aes-128-gcm group curve25519 prf hmac-sha2-256)
spi=0x0f3d60938e6d52e5: recv IKE_AUTH res 1 peer HADES:4500 local 192.168.1.102:4500, 1522 bytes, policy 'eos'
spi=0x0f3d60938e6d52e5: ikev2_ike_auth_recv: obtained lease: 10.0.3.102
spi=0x0f3d60938e6d52e5: ikev2_childsa_enable: loaded SPIs: 0x3db9a94d, 0x6abbbb01 (enc aes-128-gcm)
spi=0x0f3d60938e6d52e5: ikev2_childsa_enable: loaded flows: ESP-10.0.3.102/32=10.0.3.0/24(0)
spi=0x0f3d60938e6d52e5: established peer HADES:4500[ASN1_DN//CN=EOS] local 192.168.1.102:4500[ASN1_DN//CN=DEMETER] policy 'eos' as initiator (enc aes-128-gcm group curve25519 prf hmac-sha2-256)

However, I cannot ping anything on 10.0.1.0/24 or 10.0.3.0/24 until I restart iked. Here is my iked.conf:

ikev2 'hades' active esp \
        from dynamic to 10.0.1.0/24 \
        peer HADES \
        srcid '/CN=DEMETER' \
        dstid '/CN=HADES' \
        request address 10.0.1.102 \
        iface feth0

ikev2 'eos' active esp \
        from dynamic to 10.0.3.0/24 \
        peer EOS \
        srcid '/CN=DEMETER' \
        dstid '/CN=EOS' \
        request address 10.0.3.102 \
        iface feth0

I am running
MacOS 12.2.1 (21D62)
Darwin Kernel Version 21.3.0: Wed Jan 5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64 x86_64

[tobhe]

Hey! Would it be possible to get a dump of the kernel SAs and policies with setkey -P and setkey -PD before and after suspend? I suspect that the bug might be related to SAs not getting updated or deleted properly, the iked log looks fine as far as i can tell.