Жил был один сильный и независимый 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
gx2
VTI не стали делать?
lioncub Автор
Нет, смысла не вижу в данной конфигурации.