Жил был один сильный и независимый 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
