> > > ikev2 "LINUX-CLIENT_INET4_LAN" passive esp \ > > > from 10.88.0.0/22 to 10.88.12.0/24 \ > > > from 203.0.113.92 to 10.88.12.0/24 \ > > > peer any local 203.0.113.92 \ > > > ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \ > > > childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \ > > > srcid openbsd-server.example.com dstid linux-client.example.com \ > > > lifetime 3600 bytes 1G \ > > > psk "123123123" \ > > > tag "$name-$id" > > > > > > Updated client configuration > > > > > > ikev2 "OPENBSD-SERVER_INET4_NETS" active esp \ > > > from 10.88.12.0/24 to 10.88.0.0/22 \ > > > from 10.88.12.0/24 to 203.0.113.92 \ > > > peer openbsd-server.example.com \ > > > ikesa enc aes-256-gcm-12 prf hmac-sha2-512 group ecp521 \ > > > childsa enc aes-256-gcm prf hmac-sha2-512 group ecp521 \ > > > srcid linux-client.example.com dstid openbsd-server.example.com \ > > > lifetime 3600 bytes 1G \ > > > psk "123123123" \ > > > tag "$name-$id" > > Does it work if you remove the second "from ... to" line? It looks like the SA > payload is malformed, so the flows are the most likely cause.
No that is probably not it. > > > ikev2_next_payload: length 72 nextpayload SA > > > ikev2_add_proposals: length 0 This suggests that it might be the "childsa" option . What happens if you use the default for that on both machines?