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

RouterOS IPsec Client Fortigate VPN Endpoint

RouterOS IPsec Client Fortigate VPN Endpoint, RouterOS

eugenevdm

Guest

05.12.2013 07:59:00

У клиента 6 сайтов, использующих IPsec. Раз в неделю или даже раз в месяц IPsec внезапно перестает работать на одном из сайтов. Чтобы продемонстрировать проблему, я приложил схему. На вкладке "Установленные SA" вы увидите, что IP-адрес x.x.186.50 пытается связаться с x.x.7.73, но передается 0 байт. x.x.186.50 – это удаленный IPsec-сервер Fortigate клиента, а x.x.7.73 – IPsec-точка доступа на базе MikroTik. Судя по всему, данные с удаленной стороны к нам не всегда доходят. Фаза 1 всегда устанавливается, но Фаза 2 периодически падает. Мы пробовали разные вещи со временем, такие как перезагрузка, синхронизация времени, копание в конфигурации, многократные проверки конфигурации, но проблема кажется совершенно случайной. Иногда случайные действия решают проблему. В какой-то момент у меня возникла теория, что если туннель инициируется с их стороны, то он работает, но эксперименты с “Send Initial Contact” не привели к изменению ситуации. Мы много раз обсуждали это с клиентом, но у них гораздо больше международных IPsec VPN, и только наша конфигурация MikroTik не работает. Я также включил файл журнала. Сложно точно сказать, где именно происходит сбой в переговорах, но он зацикливается на сообщении "получен действительный R-U-THERE, ACK отправлен".

Файл журнала:
echo: ipsec,debug,packet 84 байта от x.x.7.183[500] к x.x.186.50[500]
echo: ipsec,debug,packet sockname x.x.7.183[500]
echo: ipsec,debug,packet send packet from x.x.7.183[500]
echo: ipsec,debug,packet send packet to x.x.186.50[500]
echo: ipsec,debug,packet src4 x.x.7.183[500]
echo: ipsec,debug,packet dst4 x.x.186.50[500]
echo: ipsec,debug,packet 1 times of 84 bytes message will be sent to x.x.186.50[500]
echo: ipsec,debug,packet 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf
echo: ipsec,debug,packet cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979
echo: ipsec,debug,packet 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8
echo: ipsec,debug,packet sendto Information notify.
echo: ipsec,debug,packet received a valid R-U-THERE, ACK sent

tomaskir Guest	#2 0 05.12.2013 10:27:00 Убедись, что у IPSec responder установлены настройки passive=yes и send-initial-contact=no. Это должно решить твои проблемы.

eugenevdm

Guest

07.12.2013 06:28:00

РЕДАКТИРОВАНО: Я изменил название этого поста с «фаза 2 периодически отказывается запускаться» на более общее, потому что, судя по всему, фаза 2 всё-таки запускается. Однако трафик не поступает с удалённой точки в локальный роутер, как описано в моём первом посте. Мы получили дополнительную информацию от клиента: их Fortigate лог показывает "Received ESP packet with unknown SPI". В базе знаний Fortigate есть статья, объясняющая, что это может быть связано с несовпадением SPI. http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654 Очевидное решение - включить обнаружение мёртвых пиров с обеих сторон, но мы можем сделать это только со своей. Это кажется весьма правдоподобным, учитывая постоянные сообщения "sendto information notify". Наша ситуация усложняется тем, что 5 других сайтов работают, а брандмауэр клиента находится под контролем изменений. Также, по их словам, настройка всегда работала на протяжении многих лет, поэтому они утверждают, что это не может быть ошибкой конфигурации на их стороне. Убедитесь, что IPSec responder имеет установлены параметры passive=yes и send-initial-contact=no. Я изучил документацию Fortigate и не нашёл параметров passive и send initial contact.

tomaskir Guest	#4 0 07.12.2013 10:29:00 Какой из устройств является инициатором, а какой — отвечающим?

payday Guest	#5 0 07.12.2013 10:58:00 Какая версия ROS установлена на ваших MikroTiks?

andriys

Guest

08.12.2013 09:28:00

Настройка DPD не подлежит обсуждению, так что смело включай её на своей стороне (с любым удобным тебе интервалом DPD) без риска нарушить фазу переговоров. Кстати, скорее всего, она уже включена на другой стороне.

eugenevdm

Guest

09.12.2013 14:19:00

Какой девайс является инициатором, а какой — отвечающим? Если отправка первичного контакта является показателем, то MikroTik выступает в качестве инициатора. Клиент сначала сообщил нам, что их Fortigate может быть как инициатором, так и отвечающим, но когда мы уточнили, они сказали, что такой настройки нет. Какую версию ROS вы используете на ваших MikroTik? Мы были на v6.5, но попробовали понизить до v5.26. Затем мы обновились до v6.7, так что сейчас у нас v6.7. Настройка DPD не обсуждается, поэтому вы можете безопасно включить ее на своей стороне (с любым подходящим вам интервалом DPD), не рискуя нарушить фазу согласования. И, вероятно, она уже включена на другой стороне. Спасибо. Мы экспериментировали с DPD, используя разные значения. Она включена как на удалённой стороне (Fortigate), так и на ближней стороне (MikroTik). Я прикрепил их конфигурацию для ознакомления. Я также запустил баунти на Server Fault, потому что вот-вот потеряем этого клиента. http://serverfault.com/questions/559820/mikrotik-ipsec-client-fortigate-received-esp-packet-with-unknown-spi

andriys

Guest

09.12.2013 15:21:00

Первое, что стоит заметить – настройки времени жизни phase1 не совпадают. У вас 1 день, а у них 8 часов (28800 секунд). Сделайте так, чтобы они совпадали. И убедитесь, что все остальное тоже совпадает. Установите настройку проверки предложения в значение "strict", это гарантирует, что все будет соответствовать (иначе туннель перестанет работать).

eugenevdm Guest	#9 0 11.12.2013 12:47:00 Спасибо. Мы тоже пробовали установить значение в 8 часов, но на данном этапе, в приступе раздражения, было установлено значение по умолчанию для MikroTik — 24 часа. Так что вот решение, которое опять же совершенно случайное и не имеет смысла. Я приложил ещё одну схему прямо в сообщении, чтобы показать, что произошло. Мы исправили это, выполнив следующие действия: \ Выключили PPPoE на стороне клиента. Установили совершенно новый роутер (Router B) и протестировали его на границе. Это сработало на границе. Выключили новый роутер B на границе. И ПОТОМ, НЕ ВНЕСЯ НИ ОДНОГО ИЗМЕНЕНИЯ, роутер A на стороне клиента начал работать. Так что просто добавление дублирующего роутера на границе и последующее его отключение заставило оригинальный роутер заработать. Добавьте это исправление в список того, что мы делали: Перезагрузка. Это работало один раз. Создание нового туннеля с новым IP. Это сработало один раз, но только один раз. После возвращения к старому IP клиенту вернулся в онлайн. Изменение серверов времени. Потыкать во все возможные настройки. Ждать. Однажды, через день, всё просто заработало само. В этот раз, даже через несколько дней, ничего не происходило. Поэтому я предполагаю, что есть несовместимость на стороне Fortigate или MikroTik, которая возникает только в очень случайных ситуациях. Единственное, чего мы не смогли попробовать, — это обновить прошивку на Fortigate. Возможно, там есть скрытое поврежденное значение конфигурации или проблема с таймингом, невидимая для конфигурирующего. Я также предполагаю, что проблема вызвана случайными проблемами с таймингом, вызывающими несоответствие SPI. Просто так, случайным образом. Я добавлю в этот пост, когда это произойдет снова.

Читают тему

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