Throughout the years working with ISA and TMG I notice that one of the most challenging configuration for many Admins is to correctly setup the network settings on ISA/TMG. Although we have some great content out there about the subject, such as the An Inside Look into TMG Firewall Networks by Deb Shinder and the great series of 3 articles written by Tom Shinder: Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1), Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2) and Overview of ISA and TMG Networking and ISA Networking Case Study (Part 3). Those are “most read” articles if you are planning your network configuration on TMG, add also on top of that the article Planning Forefront TMG network topology. But, in case you inherited an environment with Forefront TMG and you are experiencing weird problems, than it is time to step back and review your configuration. This post will highlight a very common configuration mistake that can cause network route issues.

Problem: clients on remote networks were randomly unable to access Internet.

Scenario: In this case the TMG Admin has the following topology that he needs to configure:

image

 

When TMG Admin opens up TMG Management Console this is what he see:

image

When he look at this he thinks it is okay. But you know what, IT IS NOT!! Here are the reasons:

  • TMG in this case just have 2 NICs (one facing Internet and the other one facing the headquarter network).
  • Forefront TMG does not support defining separate network objects that represent remote subnets

For the second bullet, I want to call out the original source of this information, which says:

Forefront TMG does not support defining separate network objects that represent remote subnets

Issue: Forefront TMG does not support defining separate network objects that represent remote subnets.

Cause: When you define IP address ranges for a network, Forefront TMG checks all network adapters. When Forefront TMG finds an adapter with an IP address in the network range, it associates the network with that adapter. When a network includes remote subnets accessible by Forefront TMG through routers, the IP address of the remote subnets should be included in the network definition. If you define a separate network object for a remote subnet (instead of including it in the network definition), Forefront TMG tries to locate an adapter with an IP address of the network object, and fails. Forefront TMG assumes that the adapter is not available (disconnected or disabled), and sets network status to disconnected.

Solution: For best practice when defining your network configuration in Forefront TMG, take note of the following:

  • Include all network ranges for subnets in a network object’s properties (for example, include subnet IP addresses in the IP address range for the internal network).
  • Apply rules to specific subnets by creating subnet objects in the Toolbox, and then using these subnet objects to specify the source and destination in access rules.

From: http://technet.microsoft.com/en-us/library/ee796231.aspx#NetworkAndRoutingIssues

This is a VERY common mistake and I’ve seen this over and over. The main argument that I also hear is: it always worked like that, why this is a problem now? Well, mainly because it is not supported, which means that Microsoft can’t guarantee that your setup will be functional with this setting. 

Resolution: The correct way to setup this particular environment is:

  • Add all IP ranges (10.10.10.0/24, 10.10.11.0/24 , 10.10.12.0/24 and 10.10.13.0/24) as part of the Internal network
  • Since TMG should not be pointing to the internal router as default gateway, make sure to create static routes (persistent) for each destination network pointing to the internal router interface as next hop.
  • Make sure that the routes on each router have the correct definition of each network and that all Internet traffic is redirected to TMG. In other words, when a client on Branch Office 2 is trying to access a web site (valid IP).

Plan your network setting, if you can’t plan, make sure to review the TMG Alerts, usually TMG is screaming out loud saying that there is something wrong in this area.