Жил был один сильный и независимый 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 found charon: 08[IKE] failed to establish CHILD_SA, keeping IKE_SA charon: 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_SEQ charon: 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

Теперь всё работает! Победа за нами! ?

По итогу, иформация от клиента (не считая внешнего IP)

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 seconds Phase 2 IKEv2 encryption: AES-256 Integrity hash: SHA256 PFS: Yes, group=20 Life‑time: 28 800 seconds

Что получилось в ipsec.conf

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

IPSec Site to Site или Strongswan to Palo Alto