Сразу выкладываю таблицу main
Альтернативные таблицы и их содержимое по одному пункту (другие два по тому же принципу, но по ван2 и бородачайписек2.
В таблице main обратите внимание на два мониторящихся айписека бородач 80 и 81 – мониторятся до remote lan_ip со стандартными значениями мониторинга.



Теперь пбр



Теперь статус, но на данные в статусе не обращайте внимания – я их скриншотил отключив фаерволл от всего. И правила (пробовал и группой по айписекам и отдельные правила по каждому).


Суть проблемы –автоматического переключения на резервный айписек не происходит! Ваны нормально переключаются.
Точнее даже так – сам айписек на резервный переключается стандартно бысто (пара минут), и в статусе самого айписека я вижу что он устанавливается и с SA всё впорядке,
но вот данные по резервному айписеку не идут и пинг не идет! И в статусе роут оба айписека стоят с буквой М.
А по идее первый должен становиться МХ.
Что помогает – так это принудительно выключение в таблице MAIN первого айписека и тогда и пинги и данные едут.
В чём может быть собака? Мониторинг? Метрики?
В айписеках дед пир включен, кип элайв выключен.

то есть ещё раз - в стандартной ситуации по первым ванам айписек устанавливается и данные сразу начинают идти, при срабатывании фэйловер ваны переключаются, резервный айписек подхватывается, но данные по нему не идут и пинги не проходят и в роут статусе первый айписек всё так же с буквой М, а должен становиться МХ.
с той стороны стоит ДСР и он мне тоже пишет, что резервный айписек эстаблиш.
В моём случае со стороны ДСР постоянно доступен только один ван, второй ван дср включается только при падении с любой из сторон первого вана. Поэтому одновременное создание двух туннелей не получится. Потому и ключ на ДФЛ для обоих айписеков использую один и тот же (это так для справки общей картины).

_________________
понял настроил забыл

а без дедпира?

щя попробую. я ещё попробую пбр на дср включить - для доступности сразу двух ванов со стороны дср.. отпишусть.

_________________
понял настроил забыл

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

_________________
понял настроил забыл

Вот что удалось найти на форуме

Настройка режима failover для ipsec .pdf
How to configure IPSec VPN failover .doc

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

да я это всё видел. дело то не в этом. всё сделано правильно, но фактическое хождение пакетов по резервному айписеку начинается только тогда когда я принудительно вырубаю первый роут на айписек в мэйн таблице (вида айписек 1 ремотнэт1) на дфл. и отключаю мониторинг по второму роутингу (вида айписек2 ремотнэт 2) там же в мэйн.
в чём может быть причина?

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

_________________
понял настроил забыл

А как у Вас настроен мониторинг? Что мониторите?

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

в мэйн таблице мониторю оба айписека вида айписек 1 ремотнет 1 80 и айписек 2 ремотнет 2 81.
мониторю только по хосту. хост это лан айпи удаленного ДСР то есть 192.168.20.1.
мониторинг хоста со стандартными параметрами - ничего не менял.

_________________
понял настроил забыл

Юрий вот по первой ссылке всё получилось. Объясните пожалуйста на пальцах в чём прикол этой конфигурации?
Я так понял, что там динамические туннели с выключенным дедом и включенным кипэлайвом. И правилами маршрутизации запрещаем использование ван 2 при рабочем ване 1.
Какие нюансы есть у этой схемы? В целом? Стабильность? Особенности?

а так - да. всё подхватывается налету и переключается. и это с учетом того, что на дальней стороне ДСР 1000 с постоянным одним ваном и второй ван включается только при недоступности первого по любым причинам, в том числе и по причине отвала первого вана у центрального дэфэля..

я так понимаю, что на удаленном дср надо тоже дедпир отключить и кипалайв включить, а то чего-то на дфл стали са одинаковые множиться при переключении ванов...

черт возьми - при отключении дедпиров и включении кипэлайва на дср становится невозможным выбрать резервную политику дср.. как быть?

нет всё-таки парочка дфл-дср - это ужоснах. не работает ничего... итог - ничего не получается. ни так ни так.

_________________
понял настроил забыл

кажется я догнал. вечером проверю - ведь маршруты на туннели вида айписек - ремотнет должны быть с метрикой приоритетнее чем маршрут на ван1 аллнетс ван1гейтвэй?
то есть так - ?

_________________
понял настроил забыл

а у меня на первом скрине метрика на туннели такая же как и на аллнетс.. кажется в этом ошибка

и ещё вопрос. правильно ли я понимаю, что для одновременной работы двух туннелей (основного и резервного) на дфл ключей должно быть две штуки? или один и тот же можно в двух туннелях указывать?
это я об этом
Routing > Routing rules
Делаете правила
wan1/all-nets any/all-nets, forward main, return alt_wan1
wan2/all-nets any/all-nets, forward main, return alt_wan2
здесь надо два ключа делать?

ipsec_remote1/all-nets any/all-nets, forward main, return alt_ipsec_remote1
ipsec_remote2/all-nets any/all-nets, forward main, return alt_ipsec_remote2

Если вам не надо одновременную доступность обоих WAN-ов, то первые два правила можно переписать в виде
wan1/remote_ip1 any/all-nets, forward main, return alt_wan1
wan2/remote_ip2 any/all-nets, forward main, return alt_wan2
вот здесь я так понимаю в двух туннелях можно один ключ выбирать

_________________
понял настроил забыл

получается что работает таким образом, как будто альтернативной таблицы нет
т.е. пока первый алнетс не грохнется по второму ваще ничего не ходит
по первой инструкции заработало потому что она не использует альтернативные маршруты, там запрос на подъем айписека кидается на группу адресов, и если туннель поднялся по второму адресу, то он будет работать только при отсутствии первого маршрута (но т.к. первый туннель привязан к ван1, то оно так и происходит)
короче альт. таблица не работает, заходите на дфл по ssh и проверяйте ее

метрика играет роль для маршрутов у которых целевая сеть одинаковая

а чтоб работал ip_sec2 через wan2, в альт. таблице должно быть два маршрута:
1) wan2 all_nets
2) ipsec2 remote_lan
я их чето не увидел
непонятно зачем использовать альт таблицы? я вижу это целесообразным если только надо гнать какой-либо трафик через второй канал до переключения
делайте через группы, как в первой инструкции

у меня в альтернативной таблице
ван 2 аллнетс ван2гэйтвей
ipsec2 remote_lan

и по первому вану тоже и по первому айписеку

метрика у всех 100
на первом скрине пример по первому вану и по первому айписеку.
альтернативная таблица вполне себе работала. до двум ванам через рдп на тачку попадал одновременно..

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

беру в мэйн таблице на ДФЛ выключаю первый маршрут на айписек вида айписек1 ремотнет.
На втором маршруте айписек2 ремотнет отрубаю мониторинг.

И вуаля! Пинги пошли, данный пошли. Но это не дело конечно. Голова моя голова.. два уха. не пойму. Может ещё скрины какие нужны?
Дедпир включать? Кипэлайв выключать? Ключей два или один?

_________________
понял настроил забыл

в логах при этом дропы есть?
не пойму зачем столько альтернативных таблиц, и правил маршрутизации многовато должно быть вроде бы одно
и зачем в правилах маршрутизации для ipsec интерфейса стоит сеть назначения all_nets?
зачем альт. таблица и правило для wan1, если это основной интерфейс и он работает через main?
при поднятом wan2 и ipsec2, пинг на уделенную сетку через какую таблицу идти пытается?
это через ssh посмотреть надо
дайте картинку c route status, при работе через wan2
повторюсь еще - по моему альтернативная маршрутизация нужна только при необходимости использования wan2 (и ipsec2) при работающем в это время wan1 и ipsec1
если этого не надо, пользуйтесь схемой "в треугольник" с группами

ок завтра дам. только по вечерам могу экспериментировать.
всё делал вот по этому мануалу. вроде лишних таблиц не делал.
в логах очень странно - по одному и тому же и коннекшен клозе и оппен. чередуются.

++++++++++++++++++++++++++++
Ну, тогда... Приведенные действия выполняются на обоих DFL зеркально

1) Objects > Address book > RemoteNetworks
Делаете объекты
remote_ip1, remote_ip2 - адреса wan1 и wan2 удаленного DFL
remote_net - lannet удаленного DFL
remote_dfl - lan_ip удаленного DFL

2) Routing > Routing tables > main
Добавляете маршруты
wan1 remote_ip1 wan1_gw 1
wan2 remote_ip2 wan2_gw 1

3) Interfaces > IPsec
Настраиваете туннели ipsec_remote1 и ipsec_remote2, автоматическое создание маршрута отключаете

4) Interfaces > Interface groups
Делаете группу ipsec_remote из ipsec_remote1 и ipsec_remote2

5) Rules > IP rules
Делаете правила
Allow ipsec_remote/remote_net core/lan_ip ping-inbound
Allow ipsec_remote/remote_net lan/lannet all_services
Allow lan/lannet ipsec_remote/remote_net all_services

6) Routing > Routing tables > main
Делаете маршруты на туннели как по FAQ (разные метрики) с применением ICMP мониторинга на remote_dfl
ipsec_remote1 remote_net 90
ipsec_remote2 remote_net 91

7) Routing > Routing tables
Добавляете таблицу маршрутизации alt_wan1 с ordering only, добавляете в нее единственный дефолтный маршрут на wan1 без мониторинга - wan1 all-nets wan1_gw 100
Аналогично для wan2 (alt_wan2)
Добавляете таблицу alt_ipsec_remote1, добавляете в нее единственный маршрут - ipsec_remote1 all-nets 100
Аналогично для ipsec_remote2 (alt_ipsec_remote2)

Routing > Routing rules
Делаете правила
wan1/all-nets any/all-nets, forward main, return alt_wan1
wan2/all-nets any/all-nets, forward main, return alt_wan2
ipsec_remote1/all-nets any/all-nets, forward main, return alt_ipsec_remote1
ipsec_remote2/all-nets any/all-nets, forward main, return alt_ipsec_remote2
Если вам не надо одновременную доступность обоих WAN-ов, то первые два правила можно переписать в виде
wan1/remote_ip1 any/all-nets, forward main, return alt_wan1
wan2/remote_ip2 any/all-nets, forward main, return alt_wan2

Такой изворот нужен для того, чтобы туннели поднимались после падения - это обеспечивается тем, что пакеты из них всегда обрабатываются через отдельную таблицу (без мониторинга). Ну и для двух туннелей необходима одновременная работа обоих WAN, поэтому необходимы альтернативные таблицы и для WAN-ов.
+++++++++++++++++++++++

_________________
понял настроил забыл