продолжаю разбираться с DFLками. и новые косяки (явно мои )

есть DFL860e в центральном офисе и есть DFLки 260 в других офисах.

Сейчас топология такая: DFL260 подключается по VPN L2TP к центральному офису на старый DFL210.
Какоето время назад появился 860 и потихоньку, в силу свободного времени копаюсь с ним с целью замены в ЦО.
У него два порта на которые приходят два провайдера (с нормальной настройкой я разбирался тут: viewtopic.php?f=3&t=170647).

Для подключения к каждому из портов делаю VPN клиент и они оба подключаются и обмен информацией идёт. НО только через тот клиент/порт, чей роут с меньшей метрикой, при этом если VPN не установлен - переход на другой не идёт. Выставлял мониторинг и метрику в роуте VPNклиентов - не помогло.

В чём я не прав и как настроить, чтобы при потере VPNканала1 он переходил роутами через VPNклиент2?

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

1) Я бы сказал, что для такой задачи IPSEC LAN-to-LAN туннели выглядят естественнее. Во всяком случае, там гораздо больше возможных настроек.

2) В настройке IPSEC туннеля в качестве remote endpoint зачем-то разрешено указывать не один адрес, а несколько. Можно предположить, что это действительно позволяет указывать альтернативные адреса для подключения, как, например, на PIXaх.

1 между ДФЛ надо протягивать IPsec канал, а не клиент-сервер, если конечно на обоих концах постоянные IP (хотя и в "клиентском" подключении между dfl есть своя "сермяжная правда":) )
2 ДФЛ позволяет реализвывать резервирование vpn, не по схеме "труб" (т.е. когда два vpn канала и один заменяет другой при отключении), а (как правильно отметил товарищ выше) создавать один канал и переключать его между доступными внешними интерфейсам (иногда говорят "перекрестное резервирование")

для разбора таких ситуаций используйте логи, status routes, status connections
и для понимания логики прохождения пакетов почитайте руководство NetdefendOS раздел по маршрутизации
например: Вы хотите подключится к vpn серверу, внешний интерфейс (wan2) которого в таблице main на втором месте (wan1 - основной), т.е. метрика больше чем у основного
как пойдет пакет? (все разрешающие правила у нас допустим есть)
пакет придет на wan2, примет ли DFL его?
да примет
т.к. стоит галка "ppp before rules", то в логах мы это не увидим, только в status connections (наверное)
как система отправит пакет обратно?
для обратной маршрутизации ей надо найти сеть назначения на внешнем интерфейсе, таблица через которую она будет осуществлять поиск - main, маршрут на алл_нетс в ней через wan1, она через него и пошлет ответ
т.е. для клиента это будет так - он послал запрос на один IP, ответа не дождался, вместо этого к нему ломятся с другого IP, на которй он запрос не отправлял (кстати в логах на стороне клиента это все хорошо будет видно)