Жил был один сильный и независимый Strongswan VPN сервер в облаках. Подключал на себя клиентов по Let's Encrypt сертификату и аутентификации, дружил с другими Strongswan... И тут как гром ⚡ среди ясного неба появился клиент с требованиями 🤘: "Хочу впн! У меня, мол, пало альто и стронгсван ваш в глаза не видывал..." Поскольку strongSwan полностью реализует протокол IKEv2, определенный в RFC 7296, то всё должно получиться! Из тех данных, что передали по Palo Alto есть интересный номер группы Diffie-Hellman, которого нет в конфигурации Strongswan. Но при штурме документации RFC были найдены соответствия групп тут (rfc5114#section-3.2) и тут (rfc5114#section-4), а также есть соответствия к настройке Strongswan тут, ну и стоит упомянуть саму документацию IANA. Собрал основные в таблицу: Имя группы Номер группы Symmetric RSA Строка в Strongswan 1024-bit MODP Group with 160-bit Prime Order Subgroup 22 80 1024 modp1024s160 2048-bit MODP Group with 224-bit Prime Order Subgroup 23 112 2048 modp2048s224 2048-bit MODP Group with 256-bit Prime Order Subgroup 24 112 2048 modp2048s256 192-bit Random ECP Group 25 80 1024 ecp192 224-bit Random ECP Group 26 112 2048 ecp224 256-bit Random ECP Group 19 128 3072 ecp256 384-bit Random ECP Group 20 192 7680 ecp382 521-bit Random ECP Group 21 256 15360 ecp521 С группами разобрались, соотнесли к настройке. Запустились 🥳, но не тут то было, получаем: parsed IKE_AUTH response 1 [ N(NO_PROP) ]generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]received AUTHENTICATION_FAILED notify error С той стороны, что-то такое: IKEv2 IKE SA negotiation is succeeded as initiator, non-rekey. Established SA: 10.10.10.10[4500]-1x.1x.1x.1x[4500] SPI:e1c24d39e8fbe6a9:cab51c19f27f54ce lifetime 28800 Sec IKEv2 child SA negotiation is failed as initiator, non-rekey. Failed SA: 10.10.10.10[4500]-1x.1x.1x.1x[4500] message id:0x0000000D. Error code 19  IKEv2 child SA negotiation failed when processing SA payload. no suitable proposal found in peer's SA payload Значит клиент точно за NAT 😡, прописываем: rightid=10.10.10.10 И видим с нашей стороны при инициализации со стороны Palo Alto: charon: 08[IKE] authentication of '10.10.10.10' with pre-shared key successful О-о-о, можно бежать за чаем.... и опять 😭: charon: 08[IKE] no acceptable proposal foundcharon: 08[IKE] failed to establish CHILD_SA, keeping IKE_SAcharon: 08[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(NO_PROP) ] Что ж... достаём из закромов свой повидавший виды, старый, потёртый, слегка в пыли - бубен! И начинаем... внимательнее смотреть наши логи. Бубен помог! charon: 08[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQcharon: 08[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256128/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ GCM против CBC - неравная схватка. Меняем в конфигурации: esp=aes256gcm16 Теперь всё работает! Победа за нами! 💪 IKE Version: 2 Phase 1 IKEv2 encryption: AES‑CBC-256 Integrity hash: SHA256 PRF hash: SHA256 Diffie‑Hellman group: group=20 Life‑time: 86 400 secondsPhase 2 IKEv2 encryption: AES-256 Integrity hash: SHA256 PFS: Yes, group=20 Life‑time: 28 800 seconds conn strongswan-to-paloalto    type=tunnel    authby=psk    left=%defaultroute    leftid=1x.1x.1x.1x    leftsubnet=10.1.1.1/24    right=2x.2x.2x.2x    rightid=10.10.10.10    rightsubnet=10.2.2.2/24    rightsendcert=never    keyexchange=ikev2    ike=aes256-sha256-ecp384    esp=aes256gcm16    ikelifetime=86400s    lifetime=28800s    dpdaction=restart    auto=start