Назад | Перейти на главную страницу

Клиент MikroTik IPsec Fortigate «Получен пакет ESP с неизвестным SPI».

У нас есть клиент с 6 сайтами, использующими IPsec. Время от времени, возможно, раз в неделю, иногда один раз в месяц, данные просто перестают поступать с удаленного VPN-сервера Fortigate на локальный VPN-клиент MikroTik IPsec.

Чтобы продемонстрировать симптомы проблемы, я приложил диаграмму. На вкладке «Установленные SA» вы заметите, что исходный IP-адрес x.x.186.50 пытается связаться с x.x.7.3, но 0 текущих байтов. x.x.186.50 - это клиентский удаленный сервер Fortigate IPsec, а x.x.7.73 - это конечная точка IPsec на основе MikroTik. Похоже, данные с удаленной стороны к нам не всегда поступают.

Фазы 1 и 2 всегда устанавливаются, но трафик всегда отказывается идти к нам с удаленной стороны.

Мы пробовали разные вещи с течением времени, такие как перезагрузка, установка часов, возня с конфигурацией, перепроверка и перепроверка конфигурации, но похоже, что проблема полностью случайна. И иногда случайные вещи исправляют. На каком-то этапе у меня была теория, что если туннель инициирован с их стороны, он работает, но возиться с «Послать начальный контакт» не изменилось.

У нас было много разговоров с клиентом об этом, но у них гораздо больше международных IPsec VPN, и только наша конфигурация MikroTik дает сбой.

Журнал Fortigate:

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654

Глядя на базу знаний Fortigate, выясняется, что SPI не согласны, и DPD может иметь значение. Но я пробовал каждую комбинацию DPD на этой стороне безрезультатно. Я хотел бы включить DPD на другой стороне, но я не могу из-за контроля изменений, а также потому, что клиент говорит, что он работает на всех других сайтах точно так же, как и конфигурация. EDIT DPD был включен

Схема локального VPN-клиента, показывающая отсутствие потока трафика:

Я включил файл журнала, показывающий непрерывные циклы "получил действительный R-U-THERE, ACK отправлен" файл журнала MikroTik:

эхо: ipsec, отладка, пакет 84 байта от x.x.7.183 [500] до x.x.186.50 [500]

эхо: ipsec, отладка, имя сокета пакета x.x.7.183 [500]

echo: ipsec, отладка, пакетная отправка пакета от x.x.7.183 [500]

echo: ipsec, отладка, пакетная отправка пакета на x.x.186.50 [500]

эхо: ipsec, отладка, пакет src4 x.x.7.183 [500]

эхо: ipsec, отладка, пакет dst4 x.x.186.50 [500]

echo: ipsec, отладка, пакет 1 раз по 84 байта сообщение будет отправлено на x.x.186.50 [500]

эхо: ipsec, отладка, пакет 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf

эхо: ipsec, отладка, пакет cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979

эхо: ipsec, отладка, пакет 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8

echo: ipsec, отладка, отправка пакета в Информационное уведомление.

echo: ipsec, отладка, пакет получил действительный R-U-THERE, ACK отправлен

Я получал различные предложения от экспертов IPsec и самих MikroTik, подразумевающих, что проблема находится на удаленной стороне. Однако ситуация значительно усугубляется тем, что работают 5 других сайтов и что брандмауэр клиента находится под контролем изменений. Установка также всегда работала в течение многих лет, поэтому они утверждают, что это не может быть ошибкой конфигурации с их стороны. Это предложение кажется правдоподобным, но я не могу его реализовать из-за контроля изменений. Я могу изменить только клиентскую сторону:

Убедитесь, что для ответчика IPSec заданы параметры passive = yes и send-initial-contact = no.

Это не сработало.

РЕДАКТИРОВАТЬ 9 декабря 2013 г.

Я вставляю дополнительные скриншоты с конфигурацией Fortigate и тем, что мы считаем переключателями быстрого режима на стороне Mikrotik.

Позвольте мне повторить, что я не думаю, что это проблема конфигурации. Я предполагаю, что это проблема синхронизации, когда сторона A или сторона B пытается слишком агрессивно отправлять информацию, что приводит к рассинхронизации согласования информации (например, SPI).

ИЗМЕНИТЬ 11 декабря 2013 г.

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

Мы исправили это:

  1. Отключение PPPoE на клиенте.
  2. Установка совершенно нового роутера (Router B) и тестирование на Border. Это сработало на Border.
  3. Выключение нового маршрутизатора B на границе. И ЗАТЕМ, БЕЗ ОДНОГО ИЗМЕНЕНИЯ, конечный маршрутизатор A клиента начал работать. Таким образом, просто добавив дублирующий маршрутизатор на границе и снова отключив этот маршрутизатор, исходный маршрутизатор заработал.

Так что добавьте это исправление в список того, что мы сделали:

  1. Перезагрузка. Однажды это сработало.
  2. Создайте новый туннель с новым IP. Это сработало один раз, но только один раз. После смены IP обратно клиентская конечная точка снова заработала.
  3. Сменить серверы времени.
  4. Поиграйте со всеми возможными настройками.
  5. Подождите. Однажды, через день, все получилось правильно. На этот раз, даже спустя несколько дней, ничего не вышло.

Поэтому я предполагаю, что существует несовместимость на стороне Fortigate или MikroTik, которая возникает только в очень случайных ситуациях. Единственное, что нам не удалось попробовать, - это обновить прошивку Fortigate. Возможно, существует скрытое поврежденное значение конфигурации или проблема с синхронизацией, невидимая для конфигуратора.

Я также предполагаю, что проблема вызвана проблемами синхронизации, вызывающими несоответствие SPI. И я предполагаю, что Fortigate не хочет «забывать» о старом SPI, как будто DPD не работает. Это происходит случайно и насколько я могу судить, только когда конечная точка A - это Fortigate, а конечная точка B - это MikroTik. Постоянные агрессивные попытки восстановить соединение «держатся» за старые значения SPI.

Я добавлю к этому посту, когда это повторится.

РЕДАКТИРОВАТЬ 12 декабря 2013 г.

Как и ожидалось, это случилось снова. Как вы, возможно, помните, у нас настроено 6 клиентских IPsec-маршрутизаторов MikroTik для конечных точек. точно так же подключение к одному серверу Fortigate. Последний инцидент снова произошел со случайным маршрутизатором, а не с тем, о котором я писал здесь изначально. Учитывая последнее исправление, в которое мы установили этот дублирующий маршрутизатор, я выбрал этот ярлык:

  1. Отключите маршрутизатор A, маршрутизатор, который больше не хочет получать пакеты от Fortigate.
  2. Скопируйте конфигурацию IPsec маршрутизатора A на временный маршрутизатор ближе к границе нашей сети.
  3. Сразу отключите вновь созданную конфигурацию.
  4. Повторно включите маршрутизатор A.
  5. Автоматически он просто начинает работать.

Глядя на комментарий @mbrownnyc, я считаю, что у нас возникла проблема с тем, что Fortigate не забывает устаревшие SPI, даже если DPD включен. Я исследую прошивку нашего клиента и выложу.

Вот новая диаграмма, очень похожая на предыдущую, но просто показывающая мое «исправление»:

Может не быть причиной вашей проблемы, но может быть полезной информацией для других пользователей. У нас была немного похожая проблема с VPN между Mikrotik и Sonicwall. Трафик останавливается случайным образом, что требует сброса SA.

В конце концов мы поняли, что Sonicwall создает отдельную SA для каждой сетевой политики (судя по вашему снимку экрана, похоже, что у вас есть 2 политики / подсети, проходящие через VPN). Я не знаю, является ли этот параметр «SA-per-policy» жестко закодированным или настраиваемым, поскольку у меня не было доступа к Sonicwall.

Наш Mikrotik использовал уровень требований для политик (по умолчанию, как показано на вашем скриншоте). Это заставляет маршрутизатор создавать единственную SA с удаленным узлом. При отправке трафика для любой из политик для этого однорангового узла он будет использовать ту же самую SA, независимо от подсети src / dest.

По сути, это означало, что он работал, пока мы использовали только одну подсеть. Как только наш Mikrotik попытается отправить трафик для второй подсети, он отправит через существующую SA (которая, насколько это касается Sonicwall, относится к конкретной паре подсетей), Sonicwall будет жаловаться, порядковые номера SA выйдут из удар, и все остановилось. (В нашем случае на стороне клиента возникла ошибка повторного воспроизведения)

В конце концов, это было так же просто, как изменить уровень политики на «уникальный», чтобы оба конца использовали уникальную SA для каждой уникальной пары подсетей. После этого туннели были совершенно счастливы.

Я знаю, что вы это проверили (как и я, когда у меня была похожая, но совершенно другая периодически возникающая проблема), но убедитесь, что у вас нет дублирующегося IP-адреса, которым делится маршрутизатор A. Это может вызвать периодическую проблему, когда ваш высокопроизводительный маршрутизатор выполняет поиск arp для маршрутизатора A и сбивается с пути. Можно подумать, что дублирование IP-адресов на маршрутизаторах будет давать постоянную ошибку, но это не так.