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

Question

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

Для того, чтобы продемонстрировать симптомы проблемы, я прикрепил диаграмму. На вкладке диаграммы Installed SAs вы увидите исходный IP-адрес xx186.50, пытающийся связаться с xx7.3, но 0 текущих байт. xx186.50 — это удаленный сервер Fortigate IPsec клиента, а xx7.73 — это конечная точка IPsec на базе MikroTik. Похоже, что данные с удаленной стороны к нам не всегда поступают.

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

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

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

Журнал Фортигейта:

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

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

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

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

echo: ipsec,debug,packet 84 байта от xx7.183[500] до xx186.50[500]

echo: ipsec,debug,packet sockname xx7.183[500]

echo: ipsec,debug,packet отправить пакет из xx7.183[500]

echo: ipsec,debug,packet отправить пакет на xx186.50[500]

эхо: ipsec,debug,packet src4 xx7.183[500]

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

echo: ipsec,debug,packet 1 раз сообщение размером 84 байта будет отправлено на xx186.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,debug,packet sendto Информационное уведомление.

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

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

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

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

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

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

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

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

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

Мы исправили это следующим образом:

1. Отключение PPPoE на клиенте.
2. Установка совершенно нового маршрутизатора (маршрутизатор 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 endpointточно так жеподключение к одному серверу Fortigate. Последний инцидент снова произошел со случайным маршрутизатором, а не с тем, о котором я изначально писал. Учитывая последнее исправление, когда мы установили этот дублирующий маршрутизатор, я выбрал этот ярлык:

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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