исправлено Сломался IPsec После прошивки v2.08(AANS.0)C2

[Makson4ik 0]

Настроен Ipsec-тунель между двумя одинаковыми Extra1, все работало отлично, была предпоследняя прошивка(которая перед v2.08(AANS.0)C2) на обоих девайсах. Обновновил до v2.08(AANS.0)C2 кинетик-клиент. После этого туннель сразу же встал, далее обновил до v2.08(AANS.0)C2 кинетик-сервер и вот тут началось.....при попытки подключения сервер пишет вот такую штуку:

13[IKE] no IKE config found for 5.228.x.xxx...78.25.1xx.xx, sending NO_PROPOSAL_CHOSEN

Клиент пишет соответственно:

 

May 03 13:29:06ipsec07[IKE] initiating IKE_SA VPN[1] to 5.228.ч.ччч

May 03 13:29:06ipsec09[IKE] received NO_PROPOSAL_CHOSEN notify error

 

Тучу раз проверил настройки, все как было раньше. Прилагаю скрины настроек сервера и клиента...надеюсь на помощь. Интересный момент - мой айфон к серверу подключается по "Сервер IPsec Virtual IP"  

Клиент.bmp

Сервер.bmp

[r13 1,003]

С этой версии (v2.08(AANS.0)C2)

IPsec: при настройке разных групп подключений, не совместимых между собой, остаются работать подключения только одной группы:
Virtual IP сервер — наивысший приоритет
туннели, которые настраиваются вручную через Web
автоматические туннели IP-IP, GRE и т.д., которые можно включить только через CLI

Выбирайте что использовать, вместе не получится.

Edited May 3, 2017 by r13

[Makson4ik 0]

6 минут назад, r13 сказал:

С этой версии (v2.08(AANS.0)C2)

IPsec: при настройке разных групп подключений, не совместимых между собой, остаются работать подключения только одной группы:
Virtual IP сервер — наивысший приоритет
туннели, которые настраиваются вручную через Web
автоматические туннели IP-IP, GRE и т.д., которые можно включить только через CLI

Выбирайте что использовать, вместе не получится.

Ничего себе, те - теперь нужно выбрать - подключать аппараты или мост между дачей ?)) Зачем это было сделано?)))))

[gaaronk 32]

11 minutes ago, r13 said:

С этой версии (v2.08(AANS.0)C2)

IPsec: при настройке разных групп подключений, не совместимых между собой, остаются работать подключения только одной группы:
Virtual IP сервер — наивысший приоритет
туннели, которые настраиваются вручную через Web
автоматические туннели IP-IP, GRE и т.д., которые можно включить только через CLI

Выбирайте что использовать, вместе не получится.

Они НЕ МОГУТ быть не совместимыми между собой.

 

Потому что настроены туннели с IKEv2, а "Сервер IPsec Virtual IP"  использует IKEv1

Для IKEv2 и IKEv1 МОЖНО использовать РАЗНЫЕ proposal (шифрование, хэш, DH).

Это просто разработчики криво реализовали логику. Хотя их понять можно, скажем для удаленного доступа используют aes128-sha1-dh14, а для туннеля 3des-md5-dh1, оба IKEv1

И при попытке поднять удаленное подключение с того IP с которого же устанавливается туннель естественно огребем NO_PROPOSAL_CHOSEN.

Вот они и перестраховались, но перетянули гайки видимо, не делая различий между IKEv2 и IKEv1.

Я бы при активации удаленного доступа и при создании туннелей версии IKEv1 просто бы делал в настройках туннелей не активными те proposal, которые на активированы в удаленном доступе.

А cli не ограничивал - если человек лезет в CLI, он понимает что делает.

 

Или бы использовал универсальную настройку для IKE.

 

Вот такую: aes128-sha1-modp1024,aes256-sha256-modp1024,aes128-sha256-modp1024,aes256-sha256-modp2048,aes128-sha256-modp2048!

 

В начале идут группы с modp1024 ибо винда 7ка по умолчанию не умеет modp2048, и при reauth если его инициирует сервер и в первой предложенной группе будет не modp1024 винда дропнет коннект.

(Ну или править реестр add a DWORD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256 "1")

aes128-sha1-modp1024 - единственный более менее приемлемый вариант для iOS младше 9ки.

 

 

 

 

[Makson4ik 0]

13 минуты назад, gaaronk сказал:

Они НЕ МОГУТ быть не совместимыми между собой.

 

Потому что настроены туннели с IKEv2, а "Сервер IPsec Virtual IP"  использует IKEv1

Для IKEv2 и IKEv1 МОЖНО использовать РАЗНЫЕ proposal (шифрование, хэш, DH).

Это просто разработчики криво реализовали логику. Хотя их понять можно, скажем для удаленного доступа используют aes128-sha1-dh14, а для туннеля 3des-md5-dh1, оба IKEv1

И при попытке поднять удаленное подключение с того IP с которого же устанавливается туннель естественно огребем NO_PROPOSAL_CHOSEN.

Вот они и перестраховались, но перетянули гайки видимо, не делая различий между IKEv2 и IKEv1.

Я бы при активации удаленного доступа и при создании туннелей версии IKEv1 просто бы делал в настройках туннелей не активными те proposal, которые на активированы в удаленном доступе.

А cli не ограничивал - если человек лезет в CLI, он понимает что делает.

 

Или бы использовал универсальную настройку для IKE.

 

Вот такую: aes128-sha1-modp1024,aes256-sha256-modp1024,aes128-sha256-modp1024,aes256-sha256-modp2048,aes128-sha256-modp2048!

 

В начале идут группы с modp1024 ибо винда 7ка по умолчанию не умеет modp2048, и при reauth если его инициирует сервер и в первой предложенной группе будет не modp1024 винда дропнет коннект.

(Ну или править реестр add a DWORD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256 "1")

aes128-sha1-modp1024 - единственный более менее приемлемый вариант для iOS младше 9ки.

 

 

 

 

Очень странных ход от разрабов......я сейчас просто откачусь и не буду голову ломать...клево еще и откатиться не получается без бэкапа...

Edited May 3, 2017 by Makson4ik
upd

[Le ecureuil 3,108]

В 5/3/2017 в 14:15, gaaronk сказал:

Они НЕ МОГУТ быть не совместимыми между собой.

 

Потому что настроены туннели с IKEv2, а "Сервер IPsec Virtual IP"  использует IKEv1

Для IKEv2 и IKEv1 МОЖНО использовать РАЗНЫЕ proposal (шифрование, хэш, DH).

Это просто разработчики криво реализовали логику. Хотя их понять можно, скажем для удаленного доступа используют aes128-sha1-dh14, а для туннеля 3des-md5-dh1, оба IKEv1

И при попытке поднять удаленное подключение с того IP с которого же устанавливается туннель естественно огребем NO_PROPOSAL_CHOSEN.

Вот они и перестраховались, но перетянули гайки видимо, не делая различий между IKEv2 и IKEv1.

Я бы при активации удаленного доступа и при создании туннелей версии IKEv1 просто бы делал в настройках туннелей не активными те proposal, которые на активированы в удаленном доступе.

А cli не ограничивал - если человек лезет в CLI, он понимает что делает.

 

Или бы использовал универсальную настройку для IKE.

 

Вот такую: aes128-sha1-modp1024,aes256-sha256-modp1024,aes128-sha256-modp1024,aes256-sha256-modp2048,aes128-sha256-modp2048!

 

В начале идут группы с modp1024 ибо винда 7ка по умолчанию не умеет modp2048, и при reauth если его инициирует сервер и в первой предложенной группе будет не modp1024 винда дропнет коннект.

(Ну или править реестр add a DWORD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256 "1")

aes128-sha1-modp1024 - единственный более менее приемлемый вариант для iOS младше 9ки.

 

 

 

 

В 2.09 сейчас ведется работа по улучшению качества проверок, в итоге будет так как описано в посте - проверяются версии протокола, режимы, настройки 1 фазы и принимается решение о совместимости или несовместимости.

Требование "чтобы всегда безукоснительно работал VirtualIP, независимо от того, что настроено еще" введено сверху, и является самой массовой фичей для пользователей, потому этот режим всегда будет вытеснять все остальные, которые с ним не будут совместимы по настройкам. А вот то, что совместимо - сейчас дорабатывается.

[gaaronk 32]

14 minutes ago, Le ecureuil said:

В 2.09 сейчас ведется работа по улучшению качества проверок, в итоге будет так как описано в посте - проверяются версии протокола, режимы, настройки 1 фазы и принимается решение о совместимости или несовместимости.

Требование "чтобы всегда безукоснительно работал VirtualIP, независимо от того, что настроено еще" введено сверху, и является самой массовой фичей для пользователей, потому этот режим всегда будет вытеснять все остальные, которые с ним не будут совместимы по настройкам. А вот то, что совместимо - сейчас дорабатывается.

С этим я абсолютно согласен. Поэтому и предложил для этого как вариант по умолчанию ввести режим "автонастройка" где для IKE и ESP подобраны параметры которые гарантированно заработают на всех клиентских устройствах и операционках.

[gaaronk 32]

23 hours ago, Le ecureuil said:

В 2.09 сейчас ведется работа по улучшению качества проверок, в итоге будет так как описано в посте - проверяются версии протокола, режимы, настройки 1 фазы и принимается решение о совместимости или несовместимости.

Требование "чтобы всегда безукоснительно работал VirtualIP, независимо от того, что настроено еще" введено сверху, и является самой массовой фичей для пользователей, потому этот режим всегда будет вытеснять все остальные, которые с ним не будут совместимы по настройкам. А вот то, что совместимо - сейчас дорабатывается.

Как сейчас сделано у меня

Есть статические туннели, есть удаленный доступ, есть туннели которые принимаются с любого адреса (на клиенте ISP каждый раз назначает новый адрес).

Пример для IKEv2

Берутся настройки IKE для каждого типа подключения и суммируются. То есть если на туннеле 3des-aes128-md5-dh1, а для RA aes128-sha1-dh14 то итог 3des-aes128-md5-sha1-dh1-dh14

 

И создается отдельный темплейт чисто под IKE, на который ссылаются соединения

Примерно так

conn tmpl-ikev2
    ike=aes256-aes128-sha256-modp2048,aes256gcm16-aes128gcm16-prfsha256-modp2048!

conn first-tun
    also=tmpl-ikev2
    <...>
  
conn IKEv2-RA-RSA
    # for windows machine certificate with full DN as local ID
    also=tmpl-ikev2
    <...>

 

[Le ecureuil 3,108]

В следующей сборке draft будет (на мой взгляд) самый оптимальный вариант с проверкой совместимости.

Если у кого-то будут проблемы с подключением - просьба заново пересоздать их (через web), чтобы убедиться, что конфиг записался верно.

[Makson4ik 0]

13 часа назад, Le ecureuil сказал:

В следующей сборке draft будет (на мой взгляд) самый оптимальный вариант с проверкой совместимости.

Если у кого-то будут проблемы с подключением - просьба заново пересоздать их (через web), чтобы убедиться, что конфиг записался верно.

те, можно будет использовать одновременно и виртуал и статический ipsec мост?

[KorDen 579]

В 10.05.2017 в 11:41, Le ecureuil сказал:

Требование "чтобы всегда безукоснительно работал VirtualIP, независимо от того, что настроено еще" введено сверху, и является самой массовой фичей для пользователей, потому этот режим всегда будет вытеснять все остальные, которые с ним не будут совместимы по настройкам. А вот то, что совместимо - сейчас дорабатывается.

А будет как-то отображаться несовместимость параметров? Чтобы не гадать "а почему у меня подключение не взлетает", а явно писалось, мол у вас несовместимые параметры для разных подключений, попробуйте следующие: ... ...

Edited May 12, 2017 by KorDen

[Le ecureuil 3,108]

3 часа назад, Makson4ik сказал:

те, можно будет использовать одновременно и виртуал и статический ipsec мост?

Да, можно.

[Le ecureuil 3,108]

1 час назад, KorDen сказал:

А будет как-то отображаться несовместимость параметров? Чтобы не гадать "а почему у меня подключение не взлетает", а явно писалось, мол у вас несовместимые параметры для разных подключений, попробуйте следующие: ... ...

Да, в базовом варианте диагностика добавлена - все будет сообщено в логе. В дальнейшем диагностику расширим, если у кого-то останутся вопросы или будет просто отключено "без объявления войны".

[ndm 5,081]

Исправлено в версии 2.09.A.7.0-3.

[r13 1,003]

@Le ecureuil С крайней прошивкой в логе были ошибки совместимости, покрутил туннели, сделал одинаково с Virtualip. Ошибки конкретизирующие проблему совместимости ушли, но все равнов логе

May 13 02:42:32ndm
IpSec::Manager: crypto map "VirtualIP" has higher priority than crypto map "4D****".
May 13 02:42:32ndm
IpSec::Manager: skip crypto map "4Dacha" due to incompatible settings with crypto map "VirtualIP".
May 13 02:42:32ndm
IpSec::Manager: crypto map "VirtualIP" has higher priority than crypto map "4L****".
May 13 02:42:32ndm
IpSec::Manager: skip crypto map "4L****" due to incompatible settings with crypto map "VirtualIP".

Селф с манипуляциями далее.

 

ЗЫ как это поможет подружить virtualip и обычное ipsec подключение между кинетиками если настройка XAuth Server  становится обязательной для всех?

May 13 03:00:03ndm
IpSec::Manager: crypto map "VirtualIP" has higher priority than crypto map "4D***".
May 13 03:00:03ndm
IpSec::Manager: crypto map "VirtualIP" has different Xauth settings from crypto map "4D***".
May 13 03:00:03ndm
IpSec::Manager: skip crypto map "4D***" due to incompatible settings with crypto map "VirtualIP".

 

Edited May 13, 2017 by r13

[KorDen 579]

@r13, у меня нормально работает VirtualIP совместно с транспортом IKEv2 AES-128/SHA1/modp2048, в том числе нормально ходит из VirtualIP в другой.

[r13 1,003]

1 час назад, KorDen сказал:

@r13, у меня нормально работает VirtualIP совместно с транспортом IKEv2 AES-128/SHA1/modp2048, в том числе нормально ходит из VirtualIP в другой.

Да, если ikev2 выставить у обычного IPSec то становится совместимо.

[Le ecureuil 3,108]

18 часов назад, r13 сказал:

@Le ecureuil С крайней прошивкой в логе были ошибки совместимости, покрутил туннели, сделал одинаково с Virtualip. Ошибки конкретизирующие проблему совместимости ушли, но все равнов логе

May 13 02:42:32ndm
IpSec::Manager: crypto map "VirtualIP" has higher priority than crypto map "4D****".
May 13 02:42:32ndm
IpSec::Manager: skip crypto map "4Dacha" due to incompatible settings with crypto map "VirtualIP".
May 13 02:42:32ndm
IpSec::Manager: crypto map "VirtualIP" has higher priority than crypto map "4L****".
May 13 02:42:32ndm
IpSec::Manager: skip crypto map "4L****" due to incompatible settings with crypto map "VirtualIP".

Селф с манипуляциями далее.

 

ЗЫ как это поможет подружить virtualip и обычное ipsec подключение между кинетиками если настройка XAuth Server  становится обязательной для всех?

May 13 03:00:03ndm
IpSec::Manager: crypto map "VirtualIP" has higher priority than crypto map "4D***".
May 13 03:00:03ndm
IpSec::Manager: crypto map "VirtualIP" has different Xauth settings from crypto map "4D***".
May 13 03:00:03ndm
IpSec::Manager: skip crypto map "4D***" due to incompatible settings with crypto map "VirtualIP".

 

Переходите на IKEv2 везде для site-to-site туннелей, оставляйте IKEv1 только для Virtual IP.

И все будет хорошо

[r13 1,003]

Только что, Le ecureuil сказал:

Переходите на IKEv2 везде для site-to-site туннелей, оставляйте IKEv1 только для Virtual IP.

И все будет хорошо

Уже понял, перешел.

[Le ecureuil 3,108]

12 часа назад, r13 сказал:

Да, если ikev2 выставить у обычного IPSec то становится совместимо.

Такова жизнь - IKEv1 сервер очень недружелюбен ко множественным конфигурациям.

[gaaronk 32]

35 minutes ago, Le ecureuil said:

Такова жизнь - IKEv1 сервер очень недружелюбен ко множественным конфигурациям.

А давайте в 2.10 для авто-туннелей опциональную команду на интерфейсе включающую ikev2 ? Все остальные настройки естественно не трогаются. По умолчанию для совместимости ikev1.

[Le ecureuil 3,108]

2 часа назад, gaaronk сказал:

А давайте в 2.10 для авто-туннелей опциональную команду на интерфейсе включающую ikev2 ? Все остальные настройки естественно не трогаются. По умолчанию для совместимости ikev1.

Да, думаем над этим.

[ndm 5,081]

Реализовано в версии 2.10.A.1.0-0.