Firewall – Forefront TMG 2010 RDP Connections without non-standard ports

NLB relies on nodes being on the same broadcast plane as each other, so doesn't usually work well in geographically distributed cluster scenarios (that, and it often costs you a lot in bandwidth broadcasting all incoming traffic across a WAN, only for it to be dropped over there).

Other clustering - perhaps, depending on what you have in mind. TMG doesn't lend itself to clustering except with its integrated NLB, so it'll have to be above (or below) the TMG level.

Having another VM ready to go in the DR site, and using DNS to direct traffic to the curent live node for internet clients, is probably the best solution. You could install this as another TMG Array member if it's used exclusively for publishing, and not enable NLB; that keeps the configuration consistent between the nodes, and allows for externally-driven failover.

You'll need the second NIC in a different subnet in order for Windows routing to be happy. Then, TMG NATs between the internal subnet, and the external subnet (using the Edge layout anyway).

To push all traffic through the TMG box, point clients to it as the default gateway. It's likely to be a fairly major change to how the network works at the moment, so have a rollback strategy.

In order to do this most easily (but with a significant change), switch the current D.G. to a different subnet (say, a 10.x subnet so it's nice and visually differentiated), plug the other TMG adapter into that subnet, and allow that subnet to be considered external by TMG (i.e. do not include it as an "internal" network) - that way, anything not in the currently-defined Internal IP range will be considered potentially hostile. (Or at least External; TMG doesn't trust Internal networks implicitly).

The 10.x network essentially becomes a DMZ of sorts - your router (I assume is currently NATting to the ISP) can forward incoming requests to the external interface on the TMG box, and TMG firewall policy will control all traffic into and out of the 192.168.1.x network.

For ease of migration, if you go with that, the internal interface of TMG should assume the old IP of the router, i.e. the already-configured-on-clients default gateway.

For advanced Web use, i.e. authentication if required, configure WPAD to give clients explicit knowledge of the proxy.

Alternatively, leave everything as it is, ignore the second NIC, and use TMG as an explicit web proxy, configured either as http://tmg:8080 on clients, or through WPAD. It won't do whole-network content filtering, but it will at least do web traffic scanning in that configuration, and allow you time to get more familiar with it before embarking on the Massive Outage Path.

Better still, test your intended setup using a lab or virtual machines.

Just a thought.

Edit: One more very, very general tip: At some point, you're going to be tempted to create a rule that says "Allow anything anywhere anytime". 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. Plus! 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.