Вводная: Два провайдера... один предоставляет PPPoE, второй через DHCP. Но... от обоих получаю статический белый IP на внешние интерфейсы. Первый канал - "толстый". Через него и планирую все и вся для офиса.... Инет, почта, ... короче - все. Второй канал - подключить 8 точек в городе по VPN для доступа к внутреннему почтовому серверу, FTP.. ну и что бы через RemoteAdmin мог попинать 1С на удаленном компьютере (базы локальные).
Абонентское оборудование на удаленке - TP-Link TL-R600VPN. База - DFL-860E. прошивка - 10.22.01.04.
Визардом прописал на WAN1 PPPoE, для WAN2 поставил Enable DHCP Client. Оба интерфейса поднялись без проблем.
DNS_Relay поднял через Гугловский DNS - работает. Клиенты из локальной сети спокойно получают WEB.
Удаленные роутеры прописаны на внешний IP второго WAN.
Как разрулить, что бы VPN траффик шел через WAN2, а все остальное -через WAN1.

Делается через PBR
http://www.dlink.ru/ru/faq/85/576.html

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

Не верно! Сутки потерял, пока настроил.
Туннель = Физический интерфейс .... а стало быть и настраивать немного не так нужно.
Что сделал.
1. Создаем новую таблицу маршрутизации (это из инструкции)
DFL-860Е - Network - Routing - Routing Tables - Add

Name: Alt
Ordering: Only

2. Создаем новый маршрут в таблице Alt (это там же)
DFL-860E - Routing - Routing Tables - Alt - Add
Interface: wan2
Network: all-nets
Gateway: wan2_gw
Local IP Address: (None)
Metric: 70

... а вот дальше уже инструкция не катит!

3. DFL-860Е - Network - Interfaces and VPN - IPSec
В созданных туннелях, в разделе Virtual Routing, в Outer PBR Table:.... выбрать таблицу Alt

То есть..... Физический интерфейс отправляем в альтернативную таблицу искать маршрут. А там, как раз по-умолчанию и стоит wan2. И прописывать Policy-based Routing Rules не требуется. Никаких!

4. Создаем разрешающее правило (опять инструкция...)

Что имеем. согласно такой схеме, туннели поднимаются через wan2. А маршрутизация пакетов из сети в сеть - по таблице main..... туннель же уже поднят.

а что мешало в таблицу main написать маршрут до удаленной точки ?

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Что мешало? ... а вот что.
В таблице main, на интерфейсе wan1 метрика - 90. На интерфейсе wan2 - 100. Что бы туннель поднять на интерфейсе wan2, необходимо метрику интерфейса сделать меньше, чем "по-умолчанию". Иначе, туннель будет пытаться подниматься через 1-й интерфейс. ... а в параметрах туннелей прописаны конечные точки для 2-го. Вот и создаем альтернативную таблицу с единственным физическим интерфейсом для того, что бы туннели поднимались именно через него. ... ну более предметно. Скажем... wan1 = 1.1.1.1, а wan2 = 2.2.2.2. Удаленные клиенты стучатся на 2.2.2.2, а маршрутизатор отвечает и пытается поднять туннель по 1.1.1.1..... авторизация не проходит и туннеля не поднимается. Посему в свойствах туннеля указал использовать альтернативную таблицу в которой только один маршрут по-умолчанию - wan2. ... и метрика этой таблицы уже значения не имеет.
Маршрутизация из сетки с сетку... по уже установленному туннелю, через таблицу main

По поводу маршрутизации для подключения туннелей и маршрутизации пакетов через установленные туннели, "курил" инструкцию. В частности, настроек Виртуальной Маршрутизации и использования параметра Outer PBR Table: ..... именно этот параметр определяет, через какую таблицу маршрутизации будет подниматься туннель

а что у вас клиенты стучатся из дикого интернета ? И вы не знаете от куда они стучатся ?
ну так в чем проблема сделать метрику меньшую через ван 2 до ваших конечных точек ?
нет ?
простой фокус ....

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Я знаю, с каких адресов стучатся удаленные клиенты. Спрашивается, зачем усложнять? ... писать дополнительные правила. В параметрах создаваемых туннелей есть опция - Outer PBR Table - то что отвечает, через какую таблицу маршрутизации будет создаваться туннель. Если есть уже готовое решение, зачем "изобретать велосипед"? В итоге, как минимум.... минус 8 PBR правил. А чем проще, тем надежнее и быстрее.

В данном случае, "форумное решение" излишне. У меня получилось вполне рабочее решение по инструкции, без дополнительных PBR и более чем понятное для меня ... Policy-based Routing Rules у меня пока вообще пустое.