General Forefront TMG 2010 network / proxy configuration
We have decided to test and then deploy a Forefront TMG server on our network of 50 - 75 users (Windows 7, XP Clients, Windows Server 2008R2 Servers and a few Linux Boxes)
Our Network Topology is:
4 Floors (4 Lan Switches) > Connected to a Core Switch in our Server Room > Core Switch Connected to our Cisco Router on FA 0/1 > Cisco Router FA 0/0 Connected to our ISP (WAN).
At this moment our DHCP is running on our cisco router and it is also the default gateway for our LAN: Default Gateway: 192.168.1.1
My Question is:
TMG Server has 2 NICs (One is Connected to our LAN Switch - TMG NIC IP: 192.168.1.200)
During Forefront TMG Installation, I added the range 192.168.1.1 - 192.168.1.254 on Adapter Selection during installation,
Once the install completes, how shall I redirect my clients, so that all network and internet traffic goes via TMG NIC 192.168.1.200
What IP Shall I assign to the 2nd NIC on the TMG Server?
Where shall that 2nd NIC be connected?
Shall I place TMG Server with DUAL NICS between our Core LAN Switch and Router or Behind the Core Switch?
Will be grateful for your assistance on this, we would use this for content filtering and web blocking and other features.
Спасибо за прочтение!
Thank you for your reply: I have more then 3 questions now:-)
Q.1: If I have 3 ISP Connections and 4NICS on our TMG Server, Can I connect all of them and have TMG Load-Balance / Failover them?
Q.2: Can TMG Dial a PPPOE Connection? say All 3 ISPs require us to dial a pppoe - is it possible to configure that for each nic?
В.3: У нас также есть маршрутизатор Cisco, действующий в качестве нашего WAN-маршрутизатора, в настоящее время подключенный только к 1 провайдеру. Когда я настраиваю TMG для балансировки нагрузки всех 3 WAN, я просто удалю cisco из топологии или как я подключу TMG а Cisco? Немного смущен здесь - буду благодарен, если вы могли бы помочь в этом - если это возможно.
В.4: Если бы на нашем TMG-сервере было ТОЛЬКО 1 (ОДИН) Nic, будет ли он подключаться к нашему коммутатору локальной сети, а затем мы указывали бы его адрес на наших клиентах W7 / XP, чтобы он действовал как сервер кэширования / веб-фильтр?
В.5: Как мы маршрутизируем весь внутренний интернет-трафик, чтобы он проходил только через наш сервер TMG - если бы мы использовали его только для кэширования и веб-фильтрации?
Еще раз спасибо за ваш ответ - я сейчас только проверяю это, я установил AD 2008R2 Box, TMG присоединен к домену и имеет 4 сетевых карты, установленных и настроенных. TMG в настоящее время подключен к нашему коммутатору локальной сети
1 ответ
Вам понадобится второй сетевой адаптер в другой подсети, чтобы маршрутизация Windows была успешной. Затем TMG NATs между внутренней подсетью и внешней подсетью (в любом случае, с использованием Edge).
Чтобы протолкнуть весь трафик через окно TMG, укажите клиентам его в качестве шлюза по умолчанию. Вероятно, это будет довольно серьезное изменение в том, как сеть работает в данный момент, поэтому используйте стратегию отката.
Чтобы сделать это проще всего (но со значительным изменением), переключите текущий DG в другую подсеть (скажем, в подсеть 10.x, чтобы она была удобной и визуально дифференцированной), подключите другой адаптер TMG к этой подсети и разрешите эта подсеть должна рассматриваться TMG как внешняя (то есть не включать ее в качестве "внутренней" сети) - таким образом, все, что не входит в определенный в настоящее время диапазон внутренних IP-адресов, будет считаться потенциально враждебным. (Или, по крайней мере, Внешний; TMG не доверяет Внутренним сетям безоговорочно).
Сеть 10.x по сути становится своего рода DMZ - ваш маршрутизатор (я полагаю, в настоящее время выполняет NAT для ISP) может пересылать входящие запросы на внешний интерфейс на коробке TMG, а политика брандмауэра TMG будет контролировать весь трафик в и из 192.168.1.x сеть.
Для простоты миграции, если вы идете с этим, внутренний интерфейс TMG должен предполагать старый IP-адрес маршрутизатора, то есть уже настроенный шлюз по умолчанию для клиентов.
Для расширенного использования в Интернете, т. Е. Для проверки подлинности, если требуется, настройте WPAD для предоставления клиентам явных сведений о прокси.
В качестве альтернативы, оставьте все как есть, проигнорируйте второй сетевой адаптер и используйте TMG в качестве явного веб-прокси, настроенного как http://tmg:8080/ на клиентах, или через WPAD. Он не будет выполнять фильтрацию содержимого всей сети, но, по крайней мере, будет выполнять сканирование веб-трафика в этой конфигурации и даст вам время ознакомиться с ним, прежде чем приступать к Massive Outage Path.
Еще лучше, протестируйте намеченную настройку, используя лабораторные или виртуальные машины.
Просто мысль.
Редактировать: еще один очень, очень общий совет: в какой-то момент у вас возникнет соблазн создать правило, которое гласит: "Разрешить что угодно в любое время в любом месте". If you do succumb to that temptation, make sure you exclude the Local Host network from it, so that at least TMG is still performing some local packet filtering to defend itself from nasty internal/external clients. (NAT tends to take care of most incoming traffic from outside, but there's always external misconfiguration to worry about).
If you want TMG to be able to connect to, or be connected to by, something, System Policy is where to do that. And as another-nother tip, if you don't allow any incoming connections to TMG other than RDP, you'll basically* be able to ignore* most* security updates* that are released*. Which is nice for the uptime. Плюс! NIS gets updates when MSRC release bulletins, so there's an additional level of protection there too. Just don't get complacent.
' * - don't do this.