Libreswan(road) to Strongswan IKEv2 using PSK the initiator (road).
The initiator request and IP address using CP. The responder has an addresspool.

Note: since strongswan seems to need special handling for proxyarp, a confirmation
ping is not used in this test case.

Note: All below errors are fixed when using current strongswan version. These are
left just in case we ever see regression.

Note: this test currently fails for strongswan 5.6.1 but works in 5.8.2
libreswan initiator sends its default proposal, using AES, AES_GCM and
MODP2048 in the KE payload, but also accepting ECP groups.

second failure seems to be a weird combination of "ip xfrm pol" where inbound
has no SPI but output has?


strongswan correctly accepts IKE_INIT:

Jan 21 21:27:39 10[CFG] received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/MODP_2048/MODP_3072/MODP_4096/MODP_8192/ECP_256, IKE:AES_GCM_16_128/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/MODP_2048/MODP_3072/MODP_4096/MODP_8192/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_512_256/HMAC_SHA2_256_128/HMAC_SHA1_96/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/MODP_2048/MODP_3072/MODP_4096/MODP_8192/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_512_256/HMAC_SHA2_256_128/HMAC_SHA1_96/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/MODP_2048/MODP_3072/MODP_4096/MODP_8192/ECP_256
Jan 21 21:27:39 10[CFG] configured proposals: IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/NEWHOPE_128/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_1024, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/CHACHA20_POLY1305_256/AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/CAMELLIA_CCM_16_128/CAMELLIA_CCM_16_192/CAMELLIA_CCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/CAMELLIA_CCM_8_128/CAMELLIA_CCM_8_192/CAMELLIA_CCM_8_256/CAMELLIA_CCM_12_128/CAMELLIA_CCM_12_192/CAMELLIA_CCM_12_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/NEWHOPE_128/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_1024
Jan 21 21:27:39 10[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256

It should really have picked the DH group from the KE payload if that was an acceptable group. It was
because the log shows "configured proposals" including modp2048.

Selecting a proposal with ECP is sub-optimal.

It then continues to fail:

Jan 21 21:27:39 10[IKE] DH group MODP_2048 inacceptable, requesting ECP_256
Jan 21 21:27:39 10[ENC] added payload of type NOTIFY to message
Jan 21 21:27:39 10[ENC] order payloads in message
Jan 21 21:27:39 10[ENC] added payload of type NOTIFY to message
Jan 21 21:27:39 10[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]

