Всем доброе время суток.
Сорри за много букв.
Столкнулся с проблемой, очень похожей на описанную здесь.
Суть в следующем.
Есть головной офис, есть удаленная точка (в перспективе их будет порядка 30). В головном офисе стоит DI-804HV (fw 1.44), подключен к Internet по Ethernet на static IP. В удаленной точке - DI-808HV (fw 1.44b11, пробовали и 1.44b06), подключены к Internet по Ethernet с помощью dynamic pppoe. Провайдер и там, и там - один и тот же.
Организован LAN-2-LAN поверх VPN. Кроме того, в удаленной точке к роутеру подключен модем (если важно - GSM; в принципе, тип модема, наверное, не имеет значения) для организации бэкапного VPN-канала на случай падения pppoe. Соответственно, в центре настроен Dynamic VPN, в удаленной точке - туннель описан статически.
В штатном режиме - все замечательно. PPPoE поднимается, VPN взлетает, LAN2LAN исправно бегает.
Физически выдергиваем WAN-ethernet из роутера - pppoe, естественно, разваливается, модем звонит, роутер получает на PSTN-порту статический IP, VPN взлетает, LAN2LAN исправно бегает. Втыкаем WAN-линк обратно - pppoe взлетает, VPN перестраивается на него, LAN2LAN исправно бегает.
Эмулируем проблему с каналом по дороге от роутера до pppoe-сервера (роутер подключен к домовой сетке, до узла провайдера - цепочка из N свитчей). То есть разваливаем pppoe БЕЗ ПОТЕРИ ФИЗИКИ на WAN-порту. PPPoE разваливается, модем звонит, роутер получает на PSTN-порту статический IP, VPN взл.... А вот отсюда начинаются грабли. VPN не взлетает. В логе удаленного роутера - вот такой бесконечный цикл (PSTN IP-адрес удаленного роутера - 85.26.138.212, IP-адрес центральной точки скрыт, сорри )

Fri Sep 21 14:43:05 2007 DOD:triggered internally
Fri Sep 21 14:43:05 2007 PPPoE start to dial-up
Fri Sep 21 14:43:05 2007 PADI:3com sent 10.0.0.1
Fri Sep 21 14:43:05 2007 Send IKE A1(AINIT) : 85.26.138.212 --> IP.IP.IP.IP
Fri Sep 21 14:43:06 2007 PADI:3com sent 10.0.0.1
Fri Sep 21 14:43:06 2007 PADI:3com sent 10.0.0.1
Fri Sep 21 14:43:07 2007 Receive IKE A2(ARESP) : [IP.IP.IP.IP]-->[85.26.138.212]
Fri Sep 21 14:43:07 2007 Try to match with ENC:3DES AUTH:PSK HASH:MD5 Group:Group2
Fri Sep 21 14:43:07 2007 Send IKE A3(AHASH) : [85.26.138.212]-->[IP.IP.IP.IP]
Fri Sep 21 14:43:07 2007 IKE Phase1 (ISAKMP SA) established : [85.26.138.212]<->[IP.IP.IP.IP]
Fri Sep 21 14:43:07 2007 Send IKE Q1(QINIT) : 192.168.181.0 --> 192.168.40.0
Fri Sep 21 14:43:08 2007 Send IKE (INFO) : delete [192.168.181.0|85.26.138.212]-->[IP.IP.IP.IP|192.168.40.0] phase 2
Fri Sep 21 14:43:08 2007 IKE phase2 (IPSec SA) remove : 192.168.181.0 <-> 192.168.40.0
Fri Sep 21 14:43:08 2007 inbound SPI = 0xfd030010, outbound SPI = 0x0
Fri Sep 21 14:43:08 2007 Send IKE (INFO) : delete 85.26.138.212 -> IP.IP.IP.IP phase 1
Fri Sep 21 14:43:08 2007 IKE phase1 (ISAKMP SA) remove : 85.26.138.212 <-> IP.IP.IP.IP

А в логе центрального роутера - такой цикл:

Friday September 21, 2007 14:49:54 Receive IKE A1(AINIT) : [85.26.138.212]-->[IP.IP.IP.IP]
Friday September 21, 2007 14:49:54 Try to match with ENC:3DES AUTH:PSK HASH:MD5 Group:Group2
Friday September 21, 2007 14:49:54 Send IKE A2(ARESP) : [IP.IP.IP.IP]-->[85.26.138.212]
Friday September 21, 2007 14:49:55 Receive IKE A3(AHASH) : [85.26.138.212]-->[IP.IP.IP.IP]
Friday September 21, 2007 14:49:56 Receive IKE A3(AHASH) : [85.26.138.212]-->[IP.IP.IP.IP]
Friday September 21, 2007 14:49:56 IKE Phase1 (ISAKMP SA) established : [IP.IP.IP.IP]<->[85.26.138.212]
Friday September 21, 2007 14:49:56 Receive IKE Q1(QINIT) : [85.26.138.212]-->[IP.IP.IP.IP]
Friday September 21, 2007 14:49:56 SPD : add dynamic user [192.168.40.0]<->[192.168.181.0] OK
Friday September 21, 2007 14:49:56 Requested routing is [192.168.181.0|85.26.138.212]<->[IP.IP.IP.IP|192.168.40.0]
Friday September 21, 2007 14:49:56 Try to match ESP with MODE:Tunnel PROTOCAL:ESP-3DES AUTH:MD5 HASH:Others PFS(Group):Group2
Friday September 21, 2007 14:49:57 Send IKE Q2(QRESP) : 192.168.40.0 --> 192.168.181.0
Friday September 21, 2007 14:49:57 Receive IKE INFO : 85.26.138.212 --> IP.IP.IP.IP
Friday September 21, 2007 14:49:57 Receive IKE INFO : 85.26.138.212 --> IP.IP.IP.IP
Friday September 21, 2007 14:49:57 Receive IKE (INFO) : delete 85.26.138.212 -> IP.IP.IP.IP phase 1
Friday September 21, 2007 14:49:57 Send IKE (INFO) : delete [192.168.40.0|IP.IP.IP.IP]-->[85.26.138.212|192.168.181.0] phase 2
Friday September 21, 2007 14:49:57 IKE phase2 (IPSec SA) remove : 192.168.40.0 <-> 192.168.181.0
Friday September 21, 2007 14:49:57 inbound SPI = 0x27080010, outbound SPI = 0x15050010
Friday September 21, 2007 14:49:57 Send IKE (INFO) : delete IP.IP.IP.IP -> 85.26.138.212 phase 1
Friday September 21, 2007 14:49:57 IKE phase1 (ISAKMP SA) remove : IP.IP.IP.IP <-> 85.26.138.212

И так продолжается до тех пор, пока либо не выдернуть кабель из WAN-порта (туннель ТУТ ЖЕ взлетает через PSTN, причем, если воткнуть WAN-кабель обратно БЕЗ восстановления pppoe, туннель ТУТ ЖЕ падает, и все возвращается к описанному выше циклу), либо не восстановить канал до pppoe-сервера (туннель взлетает через pppoe).

Вопросов, собственно, два, как обычно. Кто виноват и что делать ? Ибо пропадание линка на WAN-порту крайне маловероятно; гораздо более реально падение где-нибудь по дороге, а именно тогда-то бэкап и не работает...
Отказаться от бэкапа не предлагать, сменить провайдера выделенки - тоже.

_________________
WBR, Serhio

Небольшое дополнение/поправка:
модем GSM/GPRS, соответственно резервный канал через GPRS, провайдер - Мегафон С.З. IP адрес на резервном линке реальный, фиксированный.

Господа и техподдержкии! Прокомментируйте ситуацию, пожалуйста.

Используется ли параметр keep-alive? Если нет, то SPD не удаляется, при потере линка устройство убивает SA и создаёт заново, при сохранении линка SA не убивается.
Пропишите в keep-alive реально живущий адрес в противоположной стороне туннеля. Устройство будет следить за ответами на ping, если они будут, устройство будет считать, что туннель есть, если нет, устройство удалит всю информацию о туннеле.

На противоположной стороне поднят Dynamic VPN, т.ч. адрес для keep-alive там просто негде прописать. Со статическими VPN не получилось, т.к. туннель по резервному каналу принимающий роутер просто отказывается создавать, мотивируя это тем, что туннель в указанную сеть создавался с другого IP. М.б. мы что-то не то делаем? Изначально пробовали прописать 2 статических туннеля на исходящем (для двух целевых подсетей) и 4 туннеля на принимающем (по 2 на каждый адрес инициатора).

В Вашем случае есть одно ограничение, которое Вам мешает это отсутсвие IPSec_Failover как это реализовано, например, в DFL серии. Так что единственный выход это делать то что я рекомендовал. Или второй вариант, альтернативный -- использовать lifetime фаз == 300. После истечения таймеров, устройство сново сможет принимать соединение.

Если бы еще это можно было сделать для Dynamic VPN... Со статическими VPN организавать резервный линк реально? М.б. есть какое волшебное слово?

Попробуйте два варианта.
1. Выставить keep-alive на стороне статического туннеля
2. Выставьте времена жизни IKE/IPSec 300
И со статически IPsec на DI-8xx нереально организовать FailOver.

1. Выставлено изначально.
2. Попробуем.

Печально всё как-то. В будущих релизах прошивки можно ожидать каких улучшений в данном направлении?

В общем, пришодим к выводу, что реализация VPN через back-ip WAN неработоспособна на DI-80xHV. М.б. господа из суппорта подскажут оборудование, на котором такое чудо можно организовать?

И попутно вопрос: а почему он (роутер) smtp-сессию не хочет авторизовать? Для кого я тогда логин/пароль вбиваю?

ЗЫ: посмотрел по логам - все даже смешнее: с резервного WAN сессию авторизует, а с основного - даже не пытается