TMG и VPN-канал через другой шлюз.
 

Добрый день.
Сеть А - 192.168.8.0, TMG - 192.168.8.203, он же основной шлюз для сети, на клиентах FWC.
Сеть Б - 192.168.1.0, TMG - 192.168.1.8, он же основной шлюз для сети, на клиентах FWC.
Данные сети соединены VPN site-to-site, все нормально бегает, но ...TMG, хоть и умеет 2 ISP, но не умеет VPN с резервированием.
Для решения задачи: в каждом офисе подняты Фряхи, условно 192.168.8.205 и 192.168.1.205, настроены failover VPN каналы через двух провайдеров.
В чистовом эксперименте беру в сети А ПК без FWC, добавляю маршрут route add 192.168.1.0 mask 255.255.255.0 192.168.8.205, аналогично делаю в сети Б (цифру подсети меняю, конечно). Всё бегает, каналы держат вери гут.
Т.е. казалось бы задал всем стат маршрут через групповые политики (все клиенты сети А юзают ресурсы Б, и наоборот), но: удаляю VPNы на TMG, добавляю маршруты на компах, если на клиенте стоит FWC, то пинг и netbios например, идут через шлюзы на фряхах, минуя ису, т.е. напрямую, а вот практически любое приложение никак, все заворачиваются на ТМГ.
Пожалуйста, не предлагать удалить или отключать FWC, он стоит у всех клиентов, для пользователя все максимально прозрачно.

Поэтому вопрос: как правильно подружить TMG с каналом?

Фряху в отдельную сеть (полный аналог тээмгэшной VPN сети, только руками). На TMG маршрут к ней. FWC проксирует трафик приложения на TMG, TMG отправляет его на фряху. Правила нужно еще будет создать для обоих направлений.

Спасибо за ответ.
Но:
1. перезагрузка сервера с TMG, или его зависание приведет также к падению связи между офисами (практически 24*7 режим)
2. Почему фряхе (например сети А) выделять на внутреннем интерфейсе другую подсеть? Чем отличается от того, что если бы я маршрут в подсеть Б прописал бы через шлюз из того же диапазона сети А?

1. Вообще-то перезагрузка фряхи или её зависание даст точно такой же эффект ) Ладно. Где-то в настройках агента в консоли ТМГ можно найти поведение FWC при неудаче коннекта с TMG и прописать там альтернативный шлюз. По умолчанию, там прямой доступ к системному default gateway.
2. Если так сделать, то TMG будет ругаться на то, что адрес фряхи принадлежит сети "Внутренняя" и он не будет из внутренней во внутреннюю маршрутизировать. Поэтому надо её адрес из адресов внутренней исключить и создать отдельную логическую сеть, для которой делать свою маршрутизацию и свои правила. Если присмотритесь к встроенному VPN, то увидите как это сделано.

Вообще можно еще создать список исключений для FWC, чтобы он не трогал внутренние приложения, которым требуется только site-to-site.

1. Ну эт редко будет, надеюсь..и запускается быстро)
Системный гейтвэй - TMG. Т.е. если я пропишу доп шлюз адрес фряхи, FWC пакеты будет безо всяких авторизаций заворачивать?
2. Условно - я меняю внутренний адрес фряхи например 192.168.20.1, и на внутреннем интерфейсе TMG дописываю дополнительный IP , например 192.168.20.5 (без указания шлюза). При этом с другой стороны подсеть внутренняя на фряхе не должна быть 192.168.20.0 ?
Да, на каждом узле с TMG VPN выдает разные подсети (я не использую DHCP)

не надо так делать.
google --> DHCP option 121/249
давайте определимся о каких приложениях идёт речь.
ведь, скорее всего, приложний которые работают между двумя площадками маловато, тогда их можно прописать в исключения FWC и всё будет ок.

Да, опции эти курились, бывало..Может быть ситуация, когда не всем нужны маршруты в удаленные сети, а точнее некоторое кол-во клиентов туда и не ходит.
Приложения навскидку:
Файловые сервера >>> запуск оттуда файлов Excel, Word, JPG, PSD и другие.
1С, mstsc, ERP (несколько разных исполняемых файлов), Outlook (Exchange), radmin, антивирусный софт- обновление баз с сервера центрального филиала (один вендор).
+ ну еще что-то может быть.

простите, и вы это разруливаете через ГПО?
IMHO проще иметь маршрут у всех, а дальше (если уж очень хочется), режем ACL. на мой взгляд это идеологически верней чем резать маршрутами.
так как у меня похожая ситуация (ISA/TMG/etc только как NAT\Proxy, а железяки для Site-to-site), то я сделала немного по-другому - шлюзом по умолчанию поставила железяки, а на них всё что не в туннели - на ISA/TMG.
таким образом FWC доволен, всё что может перехватывает и пихает на ISA/TMG (для mstsc нужно исключение в FWC, для SMB нет), то, что он не ловит всё равно придёт на ISA/TMG если нужно в инет, а если нужно в site-to-site то уедет туда через железяки.

Ну на самом деле не критично, я погорячился, все клиенты, конечно.. - почта и минимум антивирус у всех точно есть)
Сетей всего - 3.
По шагам:
1. DHCP option использую обе, клиенты ХР и 7, 8.1, на серверах и на некоторых статичных машинах - маршруты ручками.
2. Удаляю VPN (правило, отношения сетей, сеть) из двух сетей в не сильно нагруженное время.
3. Шлюзами по дефолту оставляю TMG (через ТМГ, например, работает ФПСУ-клиенты, более 50 правил доступа снаружи (проброшены RDP к ПК сотрудников напрямую (удобно, если сотрудник в командировке, то как будто натурально находится за своим привычным рабочим местом), публикация почты, ФТП, обмен данными с внешними контрагентами). Фри в этом отношении не люблю, ее, конечно, обслуживают, но когда выдал список того, что мне нужно, развели ручками...
4. Создаю в ТМГ сети А объект сеть( или другую сетевую сущность?) (Б) и наоборот. Делаю правило - весь трафик разрешить для всех (резать ничего не нужно, считай локальная сеть..) Отношения сетей не делаю, получается, т.к. маршруты на клиентах. Хотя, скорее всего, видимость ТМГ нужна, если, например, человек из офиса А приехал в офис Б с ноутом и у него есть интернет через ТМг родительской сети. Соот-но, в настройки FWC нужно добавить обе сети?
5. Пишу исключения в FWC - достаточно filename.exe disabled 0 ?

при моей схеме всё так и остаётся ;)

сабнеты и траффик в обе стороны в FW правилах.
ну и route add bla bla /p на самой TMG, чтобы она не тупила, что сеть неизвестно где.
да

Если для MSTSC исключение в FWC, то как RDP коннектится к внешним серверам? Ведь у вас - дефолтный шлюз не ТМГ. Железка разрешает ?

выше же написано:

А, ну у вас железки разрешают ходить в интернет )

нет..
где вы это вычитали? О_о

MSTSC как наружу проходит, если у вас Default getway - железный маршрутизатор, в параметрах FWC - mstsc disabled 0 ?

в третий раз пишу, как всё ходит наружу:
железный маршрутизатор получает все пакеты, так как он DG для клиентов.
если пакетик бежит куда-то в Site-to-Site он идёт через этот маршрутизатор, и его туннельный интерфейс.
если пакетик бежит куда-то кроме этих Site-to-Site - он роутится на ISA/TMG, и дальше его обрабатывает ISA/TMG/etc.

итого:железяка только роутит, НАТа на ней нет вообще.
всё, что доступно через туннельные интерфейсы (у меня это 192.168.x.0/24) - гоним туда (если нет ACL), всё что не входит в 192.168.0.0/16 роутим на ISA/TMG, чтобы она разбиралась.

А, ну у вас железка роутит пакеты, т.е. Клиент-железка-ТМГ-Интернет.

именно ;)

Тогда иду по схеме, как расписал, у меня времени на отключение очень мало )
Спасибо за беседу, отпишу по мере вопросов/конфигурирования

Итак, отключил VPN на TMG, сделал на клиентах маршруты через фряхи, сделал исключения в FWC для приложений (их, кстати, около 30 вышло..)
Но, в филиале, например, стоит веб-сервер (местный портал справочный), и , соот-но, FWC направляет его на TMG, а TMG не знает куда направить трафик..
Если делать на TMG route add 192.168.5.0 mask 255.255.255.0 192.168.8.254, то не пингуется даже шлюз 192.168.5.254 (с клиентов все ок). Сделал Подсети А и Б, разрешил между ними весь трафик.

что-то не уловила.
не могу телепатировать где вы это сделали.
можно исключить обращение к сетям/доменам в настройках Internal Network через прокси и сделать их прямыми.
а чтобы это работало, нужно эти сети прописать в Internal сети TMG.
появится ругань в Alert'ах, что нет маршрута - забейте на неё.

Итак: на клиентах сети А - route add 192.168.5.0 mask 255.255.255.0 192.168.8.254 (Freebsd c VPN), в Б - route add 192.168.8.0 mask 255.255.255.0 192.168.5.254 (FreeBSD VPN).
На TMG - в параметрах FWC сделаны исключения для приложений, например, 1С disabled 1, чтобы клиент из сети А попадал в базу сеть Б.
На TMG удалили VPN site-to-site А-Б, включая правила, и объекты типа сеть.
Ес-но, из сети А не виден ТМГ в сети Б, и наоборот.
Если на ТМг добавить руками маршруты по аналогии с клиентами, то все равно, пинги на ТМГ и с ТМГ не идут.
2. Т.е. в параметре на ТМг А "Внутренняя сеть" я добавляю адреса сети Б ?

да, потому что они режутся файерволом.
и vice versa.

а потом создаёте объект Subnet (тот же, что у вас в роут адд) и прописываете туда-обратно в FW правилах.

вопрос: видимость сабнетов с самой ТМГ это критическая необходимость? :)

Гипотетически видимость бы и не нужна, но это нужно для , скажем, удаленного подключения к ТМГ из другого филиала. Или, каждая сеть - это свой , отдельный домен, т.е. все сети - домены с довериями, и в некоторых сетях, например, А, есть компьютеры и пользователи из домена Б..соот-но, в правилах ТМГ добавлены группы пользователей с доступом в интернет или к каким-то ресурсам из "тех" доменов.

Камерон, спасибо за помощь! Переключил, были нюансы, решались на ходу, в целом заработало..по этому поводу заслуженно грею кости на берегу моря )