Mikrotik.moscow [тема: все IPsec-туннели перестают работать спустя несколько дней]

все IPsec-туннели перестают работать спустя несколько дней

Fri, 09 Jan 2015 10:49:00 -0500

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Небольшое обновление: мы сделали несколько апгрейдов. Роутер теперь работает на версии 6.23, и один из ipsec-эндпоинтов теперь использует libreswan вместо racoon. К сожалению, это не помогло. Мне пришлось перезагрузить его сегодня утром. Время безотказной работы составило 2 недели и 4 дня, но во время рождественских и новогодних каникул трафика практически не было.
09.01.2015 10:49:00, vladop.

все IPsec-туннели перестают работать спустя несколько дней

Thu, 04 Nov 2021 13:17:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Это старое, но лучшее решение, которое я нашёл по этой проблеме. Ipsec зависал каждые 2-3 дня и требовал перезагрузки. Опираясь примерно на документацию и то, что здесь написано, я добавил пару строк:
/ip firewall raw add action=notrack chain=prerouting ipsec-policy=in,ipsec
add action=notrack chain=output ipsec-policy=out,ipsec

Я также убрал весь conntrack (bypass nat, fasttrack), который у меня был раньше, потому что, похоже, он больше не нужен. Надеюсь, это решит проблему, как и у предыдущего автора.
04.11.2021 13:17:00, TonyHoyle.

все IPsec-туннели перестают работать спустя несколько дней

Fri, 08 May 2020 12:42:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
У меня было то же самое. IPsec работает, но после нескольких часов нет трафика, хотя туннель всё ещё активен. Я нашёл вот это: https://mum.mikrotik.com/presentations/EU18/presentation_5143_1523360368.pdf. Изменил своё правило NAT. Во всех примерах, которые я находил для IPSec-туннеля, есть правило исключения из NAT. На странице 53 этой PDF-презентации я наткнулся на (новый?) рекомендованный способ сделать это.

/ip firewall raw add action=notrack chain=prerouting srcaddress=10.1.101.0/24 dst-address=10.1.202.0/24
add action=notrack chain=prerouting srcaddress=10.1.202.0/24 dst-address=10.1.101.0/24

страница 52: Таблица Raw
● Firewall RAW table позволяет выборочно обрабатывать пакеты без отслеживания соединений, значительно снижая нагрузку на CPU.
● Если пакет помечен для обхода отслеживания соединений:
– Фрагментация пакета не происходит.
– NAT пропускается.
– Не срабатывают опции, зависящие от отслеживания соединений (fasttrack-connection, mark-connection, layer7 и пр.)
– У пакета будет connection-state=untracked.

Пока что не тестировал несколько дней подряд, но сегодня первый день, когда туннель работает больше 24 часов. Возможно, это сработало, и кому-то ещё, кто столкнётся с такой же проблемой, тоже поможет.
08.05.2020 12:42:00, EmielB.

все IPsec-туннели перестают работать спустя несколько дней

Wed, 29 Mar 2017 09:36:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
У меня тоже такая проблема: если интернет-соединение (у меня PPPoE) быстро пропадает и восстанавливается, оно зависает на состоянии PH2 с сообщением «no phase 2». Перезагрузка роутера или удаление «remote peers» помогает восстановить соединение. Мы сталкиваемся с этим на пяти разных site-to-site соединениях. Все они на RB3011 с версиями 6.38.1 или 6.38.5.
29.03.2017 09:36:00, mattstephenson.

все IPsec-туннели перестают работать спустя несколько дней

Wed, 11 May 2016 10:42:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Извиняюсь, что возвращаюсь к старой теме, но у меня, похоже, такая же проблема на версии 6.35.2 на CCR1016-12G. Я настроил L2TP с IPsec между двумя локальными сетями на каждом из объектов. L2TP-туннели остаются активными, IPsec-туннель, кажется, устанавливается без ошибок, но если посмотреть текущий трафик в разделе «installed SAs», то в одну сторону его нет. Как только я перезагружаю роутер, трафик начинает течь в обе стороны. Буду признателен за любую помощь. Спасибо!
11.05.2016 10:42:00, martr84.

все IPsec-туннели перестают работать спустя несколько дней

Tue, 24 Mar 2015 14:52:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Я начал эту тему. Надеюсь, я не ошибаюсь, но, кажется, проблема исчезла. У меня 29 дней работы без проблем с IPsec. Я часто обновлялся, и некоторые исправления в RouterOS, похоже, помогли.
24.03.2015 14:52:00, vladop.

все IPsec-туннели перестают работать спустя несколько дней

Wed, 04 Mar 2015 12:01:00 -0500

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Привет. У меня такая ошибка на версии 6.27. Кто-нибудь знает решение?
04.03.2015 12:01:00, zolti.

все IPsec-туннели перестают работать спустя несколько дней

Wed, 15 Oct 2014 21:11:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Он снова сломался несколько дней назад. Все IPsec-соединения были недоступны, независимо от того, какие интерфейсы использовались для связи. Рад, что не нужно объяснять это клиенту.
15.10.2014 21:11:00, vladop.

все IPsec-туннели перестают работать спустя несколько дней

Thu, 02 Oct 2014 17:26:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
У меня были похожие проблемы, но только с SIP (или некоторыми UDP-подключениями) через IPSEC. Это происходило из-за «флэпа» порта на интернет-модеме или другого сбоя в интернет-соединении. Похоже, проблему решили в версиях 6.18/6.19. Однако, до выхода этих обновлений я заметил, что фиксирование скорости порта маршрутизатора для модема значительно уменьшало проблему (например, если в портах показывается, что модем автонастраивается на 100M full, нужно выключить автонастройку и зафиксировать скорость порта роутера на 100M full). После обновления прошивки я так и не возвращал скорость порта в режим автонастройки, поэтому, возможно, именно комбинация обновления прошивки до 6.18/6.19 и фикса скорости порта помогла устранить проблему.
02.10.2014 17:26:00, sanitycheck.

все IPsec-туннели перестают работать спустя несколько дней

Thu, 02 Oct 2014 06:54:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Спасибо за ваше сообщение. В логах, которые вы прислали, я не вижу ничего необычного. Я отключил DPD, но наши логи racoon тоже выглядят нормально. Вы пробовали что-нибудь делать кроме перезагрузки роутера Mikrotik? У нас два интернет-соединения. Я перенастроил один из IPsec-туннелей на канал другого провайдера. Подожду, что будет дальше. Если проблема вызвана обрывом канала, то у меня станет неработоспособными 2 IPsec-туннеля вместо всех 3-х. Для справки: во время последнего сбоя у меня было открыто две одновременные сессии между одними и теми же хостами. Одна сессия умерла, а другая еще какое-то время работала (меньше минуты), потом тоже зависла.
02.10.2014 06:54:00, vladop.

все IPsec-туннели перестают работать спустя несколько дней

Tue, 30 Sep 2014 21:14:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
Привет, vladop! У нас тоже случается похожая проблема. Немного по-другому: у нас есть IPsec между pfsense (SiteA) и Mikrotik (SiteB), и ещё один IPsec между pfsense (SiteA) и pfSense (SiteC). Всё работает отлично часами, а потом внезапно перестаёт. Обычно это происходит, когда у Mikrotik (SiteB) отваливается ADSL на минуту примерно, но не всегда. Когда такое случается, обе стороны жалуются на тайм-ауты при ожидании phase1. Если перезагрузить Mikrotik (SiteB), IPsec снова работает нормально. С IPsec между SiteA и SiteC никогда проблем не бывает. Странно то, что мы поменяли pfsense на SiteB на Mikrotik (думали, что проблема именно там), но картина сильно не изменилась. Читая ниже, думаю, может, дело в какой-то временной задержке… Логи с SiteA выглядят так (я немного исправил и заменил IP и spi на случайные значения):

2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: [218.214.147.172] INFO: DPD: remote (ISAKMP-SA spi=0d35yyyyye0b9d5b0:1cb0yyyy46cb1) кажется мёртвым.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: очищаю ISAKMP-SA spi=0d35a5byyyy5b0:1cb039yyyy46cb1.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: очищены IPsec-SA spi=510556195.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: очищены IPsec-SA spi=1307544530.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: очищены IPsec-SA spi=2888775497.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: очищены IPsec-SA spi=147348029.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: очищаю ISAKMP-SA spi=0d35a5byyyy5b0:1cb039yyyy46cb1.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: ISAKMP-SA удалён yy.yy.yy.yy[500]-xx.xx.xx.xx[500] spi:0d35a5b2yyyyy5b0:1cb0yyyyy346cb1
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: запрос IPsec-SA для xx.xx.xx.xx поставлен в очередь из-за отсутствия phase1.
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: начинаю новую фазу 1 переговоров: yy.yy.yy.yy[500]<=>xx.xx.xx.xx[500]
2014.09.30-12:46:26 : <30>Sep 30 12:46:26 racoon: INFO: начинаю режим Identity Protection.

Какие мысли?
С уважением, Ben
30.09.2014 21:14:00, phase42.

все IPsec-туннели перестают работать спустя несколько дней

Mon, 08 Sep 2014 08:53:00 -0400

все IPsec-туннели перестают работать спустя несколько дней RouterOS в форуме RouterOS.
У меня есть роутер с тремя настроенными IPsec туннелями. Обычно всё работает как надо, но через несколько дней все три туннеля одновременно перестают работать. Единственный способ исправить ситуацию — перезагрузить роутер. После перезагрузки все три туннеля снова полностью функционируют. Я не могу понять, в чём причина. Мой главный вопрос: как найти, что пошло не так, когда это происходит? На удалённых хостах в логах ничего необычного нет — только записи про истёкшие SAs и новые SAs. Конечные точки могут пинговать друг друга. Есть действующие фазы 1 (ISAKMP) и фазы 2 (SA), причём они совпадают на обеих сторонах. Если я сбрасываю эти ассоциации на роутере, новые договариваются за считанные секунды, но это не помогает. Удалённые хосты шлют AH/ESP пакеты роутеру, а вот с роутера пакеты не идут. Оборудование и ПО: RB2011UiAS, версия 6.18. Я только что обновился до 6.19 и теперь жду, когда ошибка появится снова. Это может занять неделю.
08.09.2014 08:53:00, vladop.