Здравствуйте,
У меня такая проблема:
Примерно 5-7 раз в рабочий день падает канал на 3-4 пинга, потом восстанавливается.
Что отловил в логах:

source_ip=172.17.100.1 dest_ip=172.17.100.2 spi=ebaa73ed seq=2628900 protocol=esp reason="ESP SA lookup failure" sa_lookup_failure drop

После чего ключи убиваются, создаются заново и канал поднимается.
Что за беда, как бороться?
Сам канал жив 100%, проверяли неоднократно, перебоев между точками нет.

Еще бывает:
source_ip=172.17.100.1 dest_ip=172.17.100.2 spi=c8c2c798 seq=5785 protocol=esp reason="hardware acceleration failure" hardware_acceleration_failure drop

Вот что пишет мануал на счет ошибок:
(может натолкнет на решение проблемы)

Поставил время жизни IPSEC/IKE на сутки. С утра ни одного падения.
Судя по симптомам рутеры почему-то очень долго устанавливают связь.
Скорее всего это причина. 10 секунд вместо 1-2.

такая же проблема возникла после перехода с DFL-260e на 860 (все настройки перенёс под копирку), увеличение времени жизни это единственное лечение ?

попробуйте с обоих сторон в настройках IPsec сделать
MTU=2000

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

сделал, не помогло (с такими настройками не заработал во всяком случае). вернул обратно на 1420
во время сбоя с другой стороны (ipcop) в лог валятся такие события :

"vpn" #12: responding to Main Mode
15:56:54 pluto[2258] "vpn" #12: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
15:56:54 pluto[2258] "vpn" #12: STATE_MAIN_R1: sent MR1, expecting MI2
15:56:54 pluto[2258] "vpn" #12: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT detected
15:56:54 pluto[2258] "vpn" #12: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
15:56:54 pluto[2258] "vpn" #12: STATE_MAIN_R2: sent MR2, expecting MI3
15:56:54 pluto[2258] "vpn" #12: Main mode peer ID is ID_IPV4_ADDR: 'XXXXXXX'
15:56:54 pluto[2258] "vpn" #12: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
15:56:54 pluto[2258] "vpn" #12: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
15:56:54 pluto[2258] "vpn" #12: Dead Peer Detection (RFC 3706): enabled
15:56:54 pluto[2258] "vpn" #12: the peer proposed: 192.168.1.0/24:0/0 -> 192.168.0.0/24:0/0
15:56:54 pluto[2258] "vpn" #13: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION
15:56:55 pluto[2258] "vpn" #13: discarding duplicate packet; already STATE_QUICK_R0
15:56:56 pluto[2258] "vpn" #13: discarding duplicate packet; already STATE_QUICK_R0
15:56:58 pluto[2258] "vpn" #13: discarding duplicate packet; already STATE_QUICK_R0
15:57:02 pluto[2258] "vpn" #13: discarding duplicate packet; already STATE_QUICK_R0
15:57:10 pluto[2258] "vpn" #13: discarding duplicate packet; already STATE_QUICK_R0
15:57:20 pluto[2258] "vpn" #13: discarding duplicate packet; already STATE_QUICK_R0

случайным образом отваливается и также по непонятным мне причинам может восстановиться.
причём если посмотреть в статус IPSEC то разделе IPsec IKE Status постоянно висит (даже когда пинг не проходит) запись типа
XXXXXXXX 2015-09-03 16:09:43 2015-09-04 00:09:43 3des-cbc
и если её удалить она восстанавливается.

Не понял. После изменения MTU ipsec перестал подниматься?

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

да он не то что бы перестал подниматься из-за МТУ. ситуация какая была, ВПНа нет, я изменяю МТУ и там и сям, делаю применить и активировать на ДФЛ и перезагружаю IPCOP, жду - не поднимается. я сделал вывод что МТУ в данном случае на это не влияет, потом беспорядочное удаление IKE SA, изменение МТУ c 2000 на 1500, 1450 промежуточные перезагрузки и в какой то момент он поднимается.

Присоединяюсь к вопросу, периодически падает IPSEC тунель между dfl-860e и dfl-260e.
В логах часто встречаются записи вида:
Sep 19 15:38:27 10.10.100.1 [2015-09-19 15:40:08] FW: IPSEC: prio=2 id=01800110 rev=1 event=packet_corrupt action=drop source_ip=xxxxxxxx dest_ip=xxxxxxxx spi=0x3166129c seq=368068 protocol=ESP reason="Hardware acceleration failure"

а когда туннель однозначно висит, то и такие:
Sep 19 16:38:54 10.10.100.1 [2015-09-19 16:40:35] FW: IPSEC: prio=2 id=01800111 rev=2 event=icv_failure action=drop source_ip=xxxxxxxx dest_ip=xxxxxxxxxx spi=0xac5d70b5 seq=518948 protocol=ESP reason="ESP ICV failure" packet_data=
Излечивается перезагрузкой обоих маршрутизаторов.
Промежуток между отказами можно увеличить на день или два, если заузить трубами-пайпами ширину туннеля. Что в купе с высокой утилизацией процессора маршрутизатора наталкивает на мысль, может быть маршрутизатор 860e перегревается? Но туннель виснет даже если нагрузки нет никакой.
Как вылечить ipsec туннель от зависания?

Стоит подцепиться консолью (com или ssh) - возможно в моменты появления в логах таких сообщений в консоли будет что-то поподробнее.

Еще просто версия по-бреду:
заметно "убегают" внутренние часы, а в моменты когда происходит синхронизация и коррекция времени от внешнего NTP - вылезают бяки.. где-то рядом могут быть еще ошибки с invalid sequence и т.п.
Для эксперимента я бы попробовал на обоих сторонах временно убрать синхронизацию времени или поменять источник и увеличить частоту синхронизации - тут или эта проблема вылезет более явно (сообразно увеличению частоты) либо пропадет из-за меньшего дрифта на коротких интервалах.

>Стоит подцепиться консолью
У меня настроен syslog сервер, принимает с маршрутизатора сообщения до уровня дебаг, ничего интересного не содержится. Время обновления коротких и длинных ключей ipsec (IKE SA, IPSEC SA) выставлял разное, на частоту отказа туннеля не влияет. Как отказывает туннель - следующим образом, пинг сохраняется, но доступ по cifs, smb, remote desktop становится оооочень медленный и чаще всего заканчивается ошибкой сети. Скорость копирования падает до нескольких Кбайт/сек. И, конечно, в журнале изобилие ошибок icv_failure.
> заметно "убегают" внутренние часы
Время на обоих маршрутизаторах синхронизировано одним ntp-сервером.
Если у вас возникли какие-либо идеи, делитесь!

В консоль может писаться гораздо больше. Посмотреть это не сложно.
Как образчик ikesnoop -on -verbose


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

Наблюдение за туннелем из консоли затрудняется непредсказуемым временем отказа. Это может быть когда угодно - в 4 дня, 9 вечера или 3 утра. Величина нагрузки на канал видимого влияния не имеет. Правда можно использовать expect программу линуксовую для периодического подключения и просмотра.
Синхронизация NTP происходит каждые 10 минут.
Мне казалось, что синхронизация по времени важна между маршрутизаторами при использовании сертификатов для построения туннеля, и если использовать PSK точно синхронизироваться не надо.
Я ошибаюсь?

каждые 10 минут синхронизация это imho перебор.
а по консоли - ну та же putty ну вполне живет по несколько дней, потом разве что прокруткой долго крутить

Наверное нужно обращаться в поддержку. Идеи закончились. Ошибка плавающая. Кто нибудь может поделиться работающим конфигом для dfl-860e? Я бы мог его изучить.