Далее PBR по Вашей инструкции:

Ip-правила:

Вкладки SAT для примера.. Один http и один из папки rdp... В остальных всё аналогично сделано..

А насчёт большого количества пробросов - так уж повелось в этой конторе... Требование департамента было таковым... VPN есть между 2 офисами, но его практически никто не пользует... Репликация между доменными контроллерами проходит по нему... А так - хз, для чего ещё юзают: не работаю там... Судя по статистике вообще малонагружен...

pptp пытались поднять для внешних пользователей, делали по русскоязычному мануалу netsefend os, пытались подтянуть в качестве сервера авторизации доменный контроллер внутренний - не получилось, в логи AD не смотрел, не готов пока более подробно поделиться, у департамента в Тушино с аналогичной железкой и AD тоже не срослось... Сказали забить пока... Так что pptp есть, логинятся по внутренней БД DFL, но там 2-3 человека, если пользуют, то хорошо.. ((=
Остальные к пробросам привыкли, ярлычкам RDP на рабстоле, да к урлам в браузере...

Но это так, лирика..

Ну, начнем с Routing Rules. №2 убираем, вместо него у нас №6. В №1 заменяем dst if на any. Таким образом у нас останутся №№5 и 6 для входящих и №№1, 3, 4 для исходящих, для которых приоритетней wan2. Соответственно таблица, обозванная alt (я бы ее обозвал wan2_priority) , будет только для исходящих, не путать ее с wan2_return! Правила для исходящих можно объединить в одно, сделав группу адресов wan2_users_nets. Для симметрии можно сделать еще одну таблицу wan1_priority и соответствующее правило. Но это уже эстетика . В этой таблице (или таблицах) *_priority у нас будут только маршруты в Интернет (all-nets) через оба wan, с мониторингом и разными метриками.

Насчет проброса. Рекомендуемый способ, чтобы и внешние адреса не терять и loopback был:
SAT any/all-nets -> core/wan_ip
NAT INT/int_nets -> core/wan_ip
Allow any/all-nets -> core/wan_ip
где INT/int_nets -- Ваши локальные интерфейсы и сети (в простейшем случае -- lan/lannet, но Вам нужно делать группы).

Ну, а что касается пробросов при работающем VPN, на это уже просто нет слов .

В IP-правила подробно не вникал, замечу только, что разрешать всем https и пытаться рулить http -- странно. Гугл сейчас https по умолчанию, включая и youtube, думаю и одноклассники с контактиками могут .

PS. Повнимательней перечитав, понял, что второе правило для тех исходящих, для которых приоритетней wan1 не просто для красоты, его нужно сделать (выше возвратных правил), чтобы с этих клиентов был доступен wan2_ip.
И еще. Позаботьтесть о разрешении везде пинга, будет проще отлаживать. Правила для сервиса ping-outbound. Выше всех.
NAT INT/int-nets -> WANS/all-nets ping-outbound
Allow any/all-nets -> any/all-nets ping-outbound

Спасибо, alex63, видимо пропадания пинга и были по причине, обозначенной Вами выше: отваливался мониторинг маршрутов (может, количество генерируемых ICMP запросов достигало предела, может, ещё что), пинги до основного канала отваливались по причине отсутствия правил корректного "возврата" пакетов, сеть "колбасило", потому что в routing rules участвовал интерфейс PPPoE, который помечался, как "мёртвый"... Сменили кол-во генерируемых запросов ICMP до 10000, изменил правило мониторинга маршрута (один хост по TCP мониторить, один по ICMP, минимум 1 должен отвечать), в routing rules pppoe сменили на any (в нашей конфигурации это допустимо), стало хорошо... По крайней мере сбои РТК у меня на работе наблюдались, а железка (в другом месте настраиваю) жила себе спокойно...

Замечания по поводу https... Это для тестов сделали.. У нас http рулится след. образом: пользователям разрешено всё, кроме blacklist сайтов, на серверах blacklist - * и добавлены whitelist, в котором несколько разрешённых сайтов... Есть группа пользователей VIP_users, которым всё-всё разрешено... Затык вот в чём: тот же google у VIP-пользователей открывается мгновенно, у пользователей и серверов, к которым применяются white/black-листы открывается... Но перед этим "тупит" от 3 до 7 секунд... Причём никак не зависит от наличия правила allow_https... Некритично, но странно... Делаем правило, применяем конфигурацию - открывается мгновенно, через некоторое время (условно час), начинает задерживаться... Если все http-правила отключить - всё мгновенно открывается... Не только гугл... Штук 5 сайтов, которые по https пробовали... И замечание - одноклассники, втентакле и ютуп, вроде, не умеют https и прекрасно режутся внесением URL в blacklist...

Скрины ALG для серверов (WCF и антивирус выключены):

ALG для пользователей (WCF отключен, включение-отключение ничего не даёт, кстати..)

blacklist

Простой заменой http на httpS в соответствующем адресе можно убедиться, что "вроде" умеют. Глубоко, правда, не копал, возможно какой-то контент и идет только по открытому каналу.

Что касается HTTP-ALG -- я использовал в нем только blacklist/whitelist. У Вас очень неприхотливые пользователи, что довольствуются таким суррогатом интернета . Тормозов не замечал. Попробуйте по очереди отключать всякие дополнительные фильтры (длина, тип файла, скрипты) -- возможно, виноват один из них.