+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Фаза 1 IPSec не запускается после перезагрузки, несколько IP-адресов.

Фаза 1 IPSec не запускается после перезагрузки, несколько IP-адресов., RouterOS

joelwhrs

Guest

04.11.2015 02:22:00

У меня проблема с первым этапом из двух в IPSec: при перезагрузке маршрутизатора первый этап не проходит. Появляется ошибка тайм-аута первого этапа. Как только я отключаю все внешние IP-адреса (их 4, все в одной подсети), кроме того, что используется для IPSec-соединения, всё начинает работать. Потом могу снова включить эти IP — и соединение продолжает работать. Даже если отключить IPSec, сбросить удалённых пиров, завершить все IPSec-сессии — при повторном включении IPSec всё работает. Первый этап настроен с Src. Address. Есть идеи?

ALDISBEHMANIS

Guest

19.11.2015 13:37:00

У меня примерно такая же проблема, которую сейчас решить не получается... по крайней мере у меня. Дело в том, что MT пытается достучаться до шлюза с самого низкого IP-адреса. Например, если у вас на WAN есть .3, .2, .1, и ipsec настроен с .2, то MT пытается пускать весь трафик через адрес .1 к шлюзу. Он делает NAT вашего исходящего трафика с .2 на .1 и отправляет его с .1 к удалённой стороне ipsec. Как это решить — понятия не имею. Перепробовал всё, что мог придумать, включая ipsec-peer-local ip = …2, добавление AS-маршрутов с предпочитаемым исходным адресом и т. п. — ничего в обычном режиме не помогает. Чтобы заставить это работать, приходится отключать/включать IP .1 на WAN (тогда .2 становится предпочитаемым исходящим IP), и всё работает до перезагрузки, когда .1 снова становится предпочитаемым исходящим IP.

joelwhrs Guest	#3 0 19.11.2015 13:57:00 Звучит точно как моя проблема. Самое странное — это то, что есть возможность выбрать SA Source Address в Фазе 1 правила IPSec. Я бы подумал, что именно этот IP будет использоваться как адрес источника.

ALDISBEHMANIS

Guest

19.11.2015 14:34:00

На самом деле это replay IP, но этот урод NAT’ит твой исходный IP в свой дефолтный IP для доступа к шлюзу. Я вообще не понимаю, как с этим бороться. Использовать «наименьший» IP для IPsec — просто глупая идея… даже если это и сработает…

ALDISBEHMANIS

Guest

19.11.2015 17:33:00

ок. Я нашёл решение! Видимо, у всех ваших IP на WAN одинаковая маска… а это ошибка. Все, кроме одного, должны иметь /32 (если у всех одинаковый IP-шлюз).

2.0) Firewall - NAT: добавьте правило сверху (до masquerade)
src-nat dest-addr protocol 50 action=accept

2.1) Firewall - NAT: добавьте правило сверху (до masquerade)
src-nat dest-addr protocol 17 port 500 action=accept

Конечно, не забудьте добавить ещё одно правило accept перед masquerade:
source-addr local-subnet remote-addr remote-subnet action=accept ← это позволит вашим пакетам попасть в туннель.

Проверьте, что у вас есть фильтры, которые разрешают ipsec протоколы и порты.

Не забудьте перезагрузить оба роутера, чтобы закрыть все неправильные подключения (с неправильных IP). Или убейте их вручную с обеих сторон.

…чёрт, у меня ушло 2 дня, чтобы всё заработало!

joelwhrs Guest	#6 0 21.11.2015 18:41:00 Отлично! У меня тоже было значение для сети, заданное в списке адресов. Пришлось убрать его, когда я отключил подсеть /28, иначе связь с моим шлюзом не работала. Спасибо!

royalpublishing

Guest

11.12.2015 14:36:00

Черт, у меня, похоже, всё ещё эта проблема, хотя все мои дополнительные статические NAT IP-адреса уже используют /32, и только WAN IP этого интерфейса действительно настроен с правильной маской подсети. Кстати, чтобы уточнить, в вашем пункте 2.1) вы не указали, порт 500 в правиле NAT — это src или dst порт.

joelwhrs

Guest

11.12.2015 14:46:00

Я настроил свой на любой порт. Также проверь свои адреса и убедись, что адрес, введённый в поле «Network», совпадает с адресом в поле «Address», за исключением маски подсети. Именно из-за этого у меня возникало большинство проблем.

royalpublishing Guest	#9 0 11.12.2015 16:18:00 Просто из любопытства, вы используете Dead Peer Detection на своих IPSec-пирах? У меня он отключен, и мне интересно, может ли при обрыве связи в сети это как-то влиять на мою проблему.

joelwhrs Guest	#10 0 12.12.2015 16:51:00 На моём устройстве обнаружение мёртвых пиров отключено. Что именно происходит с твоим подключением?

royalpublishing

Guest

#11

14.12.2015 15:41:00

Периодически в логе появляются такие ошибки, и VPN, похоже, не хочет восстанавливать соединение в течение длительного времени. phase1 negotiation failed due to send error. 11.22.33.44[500]<=>44.33.22.11 053e1ceacf95ca3b:3c9b14518f30b19c. Я попробовал добавить эти дополнительные правила NAT в начало списка, теперь нужно подождать и посмотреть, вернётся ли проблема.

royalpublishing

Guest

#12

24.03.2016 14:08:00

У меня по-прежнему возникает эта случайная проблема, несмотря на добавление всех упомянутых NAT-правил и прочего. Как я уже говорил, когда это случается, весь VPN-трафик между двумя сайтами прекращается. Не уверен, как дальше с этим разбираться, может, у кого-то есть идеи, что попробовать?

mattstephenson

Guest

#13

31.03.2017 00:32:00

У меня это тоже было в предыдущих версиях, но всё ещё на 6.38.5 и на нескольких разных сайтах с RB3011. Обычно это проявляется при запуске роутера, но, кажется, случается и спорадически, возможно, когда на одном из концов падает соединение. Я оставлял это на часы, и оно всё равно продолжает заполнять лог ошибками. Если очистить «remote peers», соединения сразу же восстанавливаются и меняются на «established».

sjoram Guest	#14 0 24.08.2019 16:06:00 Всем привет, только что наткнулся на это после обновления ПО до ROS, значит, скорее всего, изменилось поведение между версиями. У меня была правило srcnat в начале цепочки NAT-правил: chain=srcnat src=10.0.0.0/8 dst=10.0.0.0/8 action=accept. Похоже, оно маскарадировало самый низкий IP на WAN-интерфейсе. Как и у других, я отключил остальные IP, и всё заработало. Затем я изменил правило на chain=srcnat src=10.0.0.0/8 dst=10.0.0.0/8 out-interface= action=src-nat to-address=, после чего включил остальные публичные IP, убил активные соединения, и сессия восстановилась нормально. Похоже, это вызывает некоторые побочные эффекты на стороне LAN, которыми я сейчас занимаюсь.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры