Проблема с не поднятием ipsec

[rodley]

Есть 2 офиса, в одном стоит pfSense 2.4.4 , в другом стоит Draytek 2960.
Draytek стоит за adsl роутером провайдера. Настроен IPsec тоннель между draytek и pfSense. pfSense в роли ответчика, IKEv2, NAT-T на Draytek включен. Периодически происходит поднятие еще нескольких фаз 2, после чего трафик перестает ходить. Как с этим бороться?

[werter]

Добрый.

Обновить ПО на Драйтеке.
АДСЛ модем перевести в режим bridge. Пусть Драйтек поднимает линк. Плодить сущности в виде двойного НАТ-а не стоит.

[Konstanti]

@rodley
Здр
По какой-то причине при обновлении ключей фазы 1 иногда Strongswan создает несколько child_sa.
Так как была похожая проблема поборол ее так
написал маленькую программу , которая использует протокол vici

https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici_README.html

Теперь при наступлении события child-updown программа проверяет , сколько записей находится в SADB после обновления ключей .
Если записей больше 1 , то программа посылает сигнал strongswan-у на удаление определенной записи из списка соединений

Выглядит это приблизительно так (создались SA 863 и 865) - 863 удаляется

Oct 24 01:13:26 Received command "FIND"
Oct 24 01:13:26 Child SA is UP, SA uniquied is #863,IKE uniqueid is #127,number of active SA: 1
Oct 24 01:13:26 Waiting for connection...
Oct 24 01:13:27 Accepted connection,receiving data  ....
Oct 24 01:13:27 Received command "FIND"
Oct 24 01:13:27 Child SA is UP, SA uniquied is #865,IKE uniqueid is #127,number of active SA: 2
Oct 24 01:13:27 Accepted connection,receiving data  ....
Oct 24 01:13:27 Received command "TERM"
Oct 24 01:13:27 Received packet for delete SA , SA uniqueid #863,IKE uniqueid #127 remote host XXX.XXX.XXX.XXX,local host XXX.XXX.XXX.XXX, spi 0xca31a2fd 
Oct 24 01:13:27 Child SA with uniqueid #863 found in SADB,deleting...
Oct 24 01:13:27 [IKE] closing CHILD_SA con2000{863} with SPIs ca277f42_i (0 bytes) ca31a2fd_o (0 bytes) and TS XXX.XXX.XXX.XXX=== XXX.XXX.XXX.XXX
Oct 24 01:13:27 [IKE] sending DELETE for ESP CHILD_SA with SPI ca277f42
Oct 24 01:13:27 [ENC] generating INFORMATIONAL request 4 [ D ]
Oct 24 01:13:27 [NET] sending packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (80 bytes)
Oct 24 01:13:27 [NET] received packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (80 bytes)
Oct 24 01:13:27 [ENC] parsed INFORMATIONAL response 4 [ D ]
Oct 24 01:13:27 [IKE] received DELETE for ESP CHILD_SA with SPI ca31a2fd
Oct 24 01:13:27 [IKE] CHILD_SA closed
Oct 24 01:13:27 SA with uniqueid 863 has deleted successfully
Oct 24 01:13:27 Waiting for connection...

как вариант поиграться с lifetime фазы 1 , чтобы инициировал обмен ключей Drytec (те его lifetime фазы 1 должен быть меньше чем lifetime фазы 1 strongswan pfsense)

[rodley]

@werter said in Проблема с не поднятием ipsec:

Добрый.

Обновить ПО на Драйтеке.
АДСЛ модем перевести в режим bridge. Пусть Драйтек поднимает линк. Плодить сущности в виде двойного НАТ-а не стоит.

Увы, это проблема.

[werter]

@rodley
Жаль. Оч. часто это помогает. Иначе в будущем могут вылезти и др. проблемы. Двойной NAT - штука опасная (

Оф. дока https://www.draytek.com/support/knowledge-base/5428

Попробуйте сменить тип шифрования на 3DES, если у вас оно на AES сейчас живет.

Общая и обязательная рекомендация - смотрите логи в момент проблемы. Всегда и везде, где это возможно.

[rodley]

@Konstanti said in Проблема с не поднятием ipsec:

как вариант поиграться с lifetime фазы 1 , чтобы инициировал обмен ключей Drytec (те его lifetime фазы 1 должен быть меньше чем lifetime фазы 1 strongswan pfsense)

Именно фазы 1, не фазы 2? Фаза 1 и там и там установлена сейчас 28800 сек, фаза 2 - 3600 сек .

[rodley]

@werter
Да, шифрование 3DES установлено. ПО на драйтеке последнее, свежее пока нету.

[Konstanti]

@rodley
Проблема возникает тогда , когда идет обновление ключей фазы 1
По крайней мере , у меня так было
Посмотрите логи , кто являлся инициатором обмена ключей , когда начинают плодиться SA.
У меня четко было видно , как это происходит
Почему так происходит - я пока не разобрался
Я не утверждаю , что это поможет , но все-таки возможно и такое
Есть еще вот такая опция у Strongswan-а

Некоторые советуют ее , но мне не помогла
Она работает только в том случае , если обе стороны поддерживают эту опцию

[werter]

@rodley
Попробуйте настройки отсюда www.cyberciti.biz/faq/howto-site-to-site-ipsec-vpn-between-cisco-openbsd-router-pfsense/

[Konstanti]

@rodley Специально посмотрел сейчас старые логи

Там где инициатором обмена ключей был Strongswan PFSense, там и плодились SA
Попробуйте все-таки поиграться с lifetime фазы 1 , мб поможет
Напишите потом , помогло или нет

[rodley]

@Konstanti

@Konstanti said in Проблема с не поднятием ipsec:

@rodley Специально посмотрел сейчас старые логи

Там где инициатором обмена ключей был Strongswan PFSense, там и плодились SA
Попробуйте все-таки поиграться с lifetime фазы 1 , мб поможет
Напишите потом , помогло или нет

Нет, не помогло. Но по итогу получилось настроить модем в режиме моста и поднять соединение на Draytek. После этого проблем не было, туннель поднялся без вопросов.

[werter]

Добрый.
@rodley
Как говорится, ЧиТД. Здраво )

Зы. ПО на модеме перед этим обновили? ) На будущее, т.с.

[Konstanti]

@rodley Покажите логи момента обмена ключами со стороны Strongswan, когда проявится проблема (если проявится )
Но , по-моему, это "глюк" strongswan-а какой-то
Я видел много сообщений в разделе IPSEC , где были несколько SA при одинаковых селекторах трафика .

[werter]

@Konstanti

Там для настройки ipsec нужно пробрасывать не только порты, но и протокол + делать статик нат на порт. В его связке АДСЛ-модем в режиме роутера, возможно, ломал эту схему. В режиме же бриджа он этому не мешает.

Зы. И снова начинаете решение ТЗ со сложного (

[Konstanti]

@werter Как может модем ломать что-то , если Strongswan сам чудит
Вот лог появления 3-х SA (часть лога вырезана)

Oct 24 00:13:26 11[ENC] <337> parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH N(USE_TRANSP) N(ESP_TFC_PAD_N) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) 
Установлена первая SA
Oct 24 00:13:26 11[IKE] <es_ru_pfsense_ecdsa|337> IKE_SA es_ru_pfsense_ecdsa[337] state change: CONNECTING => ESTABLISHED
Oct 24 00:13:26 11[IKE] <es_ru_pfsense_ecdsa|337> CHILD_SA es_ru_pfsense_ecdsa{2570} established with SPIs ca31a2fd_i ca277f42_o and TS XXX === XXX
Пришел запрос на создание второй SA
Oct 24 00:13:27 13[NET] <es_ru_pfsense_ecdsa|337> received packet: from XXXXXX[500] to XXXXXXX[500] (224 bytes)
Oct 24 00:13:27 13[ENC] <es_ru_pfsense_ecdsa|337> parsed CREATE_CHILD_SA request 2 [ N(USE_TRANSP) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Oct 24 00:13:27 13[IKE] <es_ru_pfsense_ecdsa|337> CHILD_SA es_ru_pfsense_ecdsa{2571} established with SPIs cb52e82b_i c721a072_o and TS XXXXXXX === XXXXXX
Oct 24 00:13:27 13[ENC] <es_ru_pfsense_ecdsa|337> generating CREATE_CHILD_SA response 2 [ N(USE_TRANSP) SA No TSi TSr ]
И вот пришел третий запрос на создание SA
Oct 24 00:13:27 11[ENC] <es_ru_pfsense_ecdsa|337> parsed CREATE_CHILD_SA request 3 [ N(USE_TRANSP) N(ESP_TFC_PAD_N) SA No TSi TSr ]
Oct 24 00:13:27 11[IKE] <es_ru_pfsense_ecdsa|337> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Oct 24 00:13:27 11[IKE] <es_ru_pfsense_ecdsa|337> CHILD_SA es_ru_pfsense_ecdsa{2572} established with SPIs c33b831c_i c84314cd_o and TS XXXXXXX === XXXXXXX

Те вот так на ровном месте при обновлении ключей фазы 1 Strongswan создает 3 SA
Возможно этому есть какое-то логическое объяснение , но я пока с этим не разбирался
Пошел более простым путем
Но явно ноги растут от инициатора

Вот перевод от разработчика Strongswan

Это известная проблема, если вы объединяете break-before-make reauthentication с политиками trap. Существует короткое время после того, как старый SA был прекращен, и в то время как новый установлен, в течение которого никакой SA не установлен в ядре. Но так как политики ловушек все еще установлены, новые приобретения могут быть вызваны ядром, если в это время произойдет совпадение трафика, что создаст дополнительный CHILD_SA (который, в свою очередь, будет воссоздан во время следующей повторной проверки подлинности). Чтобы избежать этого, либо используйте make-before-break reauthentication (создает новое перекрытие IKE и CHILD_SAs), либо просто используйте IKE_SA rekeying для замены ключевого материала без каких-либо перерывов

Об этой опции я писал выше

[Konstanti]

@rodley
Еще в догонку
Попробуйте вот такую опцию в настройках фазы 1

Тогда по уму не должны удаляться CHILD_SA при обновлении ключей IKE_SA

[rodley]

@werter
Нет, ПО я не обновлял, модем провайдерский и в другой стране. У меня там только Draytek стоит за этим модемом. Но там ещё и интернет говно :(