کد:
http://blog.msedge.org.uk/2010_04_01_archive.html
I noticed from the TechNet forums that many people are beginning to use UAG who have not had much experience of TMG, or its predecessor ISA Server. Although you do not necessarily need to understand the TMG platform which sits below UAG, as much of its configuration is automated, it certainly does help. This is especially true when it comes to understanding core networking concepts when UAG is used in large/complex networks or aspects like monitoring traffic flow for troubleshooting purposes.
Having come from an ISA/TMG background myself, the transition to UAG has involved many new concepts and lots of new challenges. However, I have been finding myself ‘falling back’ on old ISA knowledge more and more, in order to deploy, configure and troubleshoot UAG solutions.
Unfortunately, not everyone deploying UAG is lucky enough to have this type of previous experience and consequently I thought it may be useful to cover some TMG fundamentals to get those UAG admin folks started.
Please Note: This is not an exhaustive list of TMG concepts, but hopefully covers the key areas that are relevant to an initial Forefront UAG deployment. Introduction
Before I start, it is useful pointing out that Forefront UAG uses Forefront TMG as follows:

  • Forefront TMG acts as a firewall, protecting the Forefront UAG server.
  • Forefront UAG uses Forefront TMG infrastructure and functionality in some deployment and monitoring scenarios.

Technically, TMG is natively fully configurable and the TMG management console is not limited in any way. However, by making undesirable changes to TMG you can soon find yourself in an unsupported scenario if you need to call Microsoft support. Therefore, the best way to explain what functionality is supported, and more importantly, what isn’t supported is to review the following TechNet article:
UAG Support Boundaries
This document is an evolving document which covers the support boundaries for UAG, specifically including the use of TMG. At the time of writing the Supported Forefront TMG Configurations section includes the following statement:
You can use Forefront TMG running on the Forefront UAG server, as follows:

  • Creating access rules using the Forefront TMG Management console, for the purpose of limiting users, groups, and networks for granular access when deploying Forefront UAG for VPN remote network access.
  • Monitoring with the Forefront TMG Management console.
  • Limiting users, groups, sources and destinations on Forefront TMG system policy rules, with the purpose of enabling access to corporate servers and remote management to and from the Forefront UAG local host server.
  • You can publish the following applications via Forefront TMG:
    • Exchange SMTP/SMTPS
    • Exchange POP3/POP3S
    • Exchange IMAP/IMAPS
    • Office Communications Server (OCS)

Therefore, for the purposes of this blog post, the TMG fundamental areas I plan to include are:

  • Networking
  • Monitoring
  • Systems Management
  • Server Publishing

By using TMG as the firewall and network platform below UAG, Microsoft empowers those with appropriate ISA/TMG knowledge to better understand and control the overall UAG deployment.
Anyhow, lets get started…
Networking
Correct network setup is essential for any gateway solution, especially those with multiple network interfaces connected to disparate networks.
Although networking is not covered within the support boundaries document, Forefront UAG must be installed on a computer with at least two network adapters as detailed here. Furthermore, best practice dictates that for TMG/UAG:

  • Only one network interface should be configured with a default gateway.
  • Both network interfaces cannot be connected to the same network subnet/segment.

More information on recommended network card configuration can be be found in my recent blog post here: Recommended Network Card Configuration for Forefront UAG Servers.
Therefore, the correct configuration of network cards, and networking setup in general, are crucial to a successful UAG deployment. If you are placing UAG into a simple network, the use of two network cards combined with a single default gateway may not be a problem. However, if we consider the more complicated scenarios that are likely occur, we can see that the correct network routing is vital.
Scenario 1: Router or Layer 3 Switch Between UAG and Internal/Published Servers

Given the above scenario, we can see that a different network exists behind an internal router (or a layer 3 switch if using a VLAN based environment). This network may contain some or all of the internal/published servers. In our case, this is the 192.168.1.0/24 network. As UAG is defined with a default gateway on the external interface, it will not be possible to natively communicate with the routed internal network as all requests for the 192.169.1.0/24 network will be sent to the external network interface. To solve this problem, we need to add a persistent static route to UAG using the following command in an elevated command prompt:
route add –p 192.168.1.0 mask 255.255.255.0 [IP Address of Router or Layer 3 Switch]
Please Note: In the event that multiple networks exists behind an internal router/switch, it will be necessary to add multiple persistent static routes. Alternatively, it is possible to define a ‘supernet’ static route like 192.168.0.0/16 to encapsulate all constituent networks in a single route statement. If these static routes are added before UAG is installed, you should be presented with the following aggregated address ranges during the Configure Network Settings section of the Getting Started Wizard:

However, if these static routes are added after UAG is installed, it will be necessary to manually run the Network Configuration Wizard by selecting the Network Interfaces… option from the Admin menu of the UAG Management Console.
When presented with the Define Internal Network IP Address Range window, click Add and enter the relevant networks which match your newly added persistent static route entries. In our case this would simply be: From IP address: 192.168.1.0 and To IP address: 192.168.1.255 as shown below:

So, if after configuring UAG, we look at the Internal Network object in the TMG Management console, we can see that the network address ranges have been inherited by TMG, from UAG.

Scenario 2: UAG in Perimeter Network with Back Firewall Between UAG and Internal/Published Servers
Based upon my experience of UAG so far, this is likely to be a more common scenario, especially for enterprise customers. An overview of the associated architecture is shown below:

Given the above scenario, we can see that a different network exists behind an internal firewall with internal/published servers existing on one (or many) internal networks. In our our case, this is the 192.168.1.0/24 network. As UAG is defined with a default gateway on the external interface, it will not be possible to natively communicate with the routed internal network as all requests will be sent to the external network interface. To solve this problem (as before) we need to add a persistent static route to UAG using the following command in an elevated command prompt:
route add –p 192.168.1.0 mask 255.255.255.0 [IP Address of Back Firewall]
Please Note: In the event that multiple networks exists behind an internal router/switch, it will be necessary to add multiple persistent static routes. Alternatively, it is possible to define a ‘supernet’ static route like 192.168.0.0/16 to encapsulate all constituent networks in a single route statement. As per scenario 1, if these static routes are added before UAG is installed, they will be included within the Configure Network Settings section of the Getting Started Wizard. If these static routes are added after UAG is installed, it will be necessary to manually run the Network Configuration Wizard as described above.
So, you might ask why is this Internal Network definition so important?
Well, the Internal network object within TMG is a predefined network that represents the primary default protected network and is generally considered to contain protected IP address ranges. Conversely, the External Network object within TMG includes all addresses that are not defined as part of the Internal Network.
When the internal network includes remote subnets that are only accessible by TMG through routers, it is vital that the IP addresses of the remote subnets should be included in the Internal Network definition. If not, TMG will consider them part of the External Network (based upon the definition above) and consequently deny traffic as spoofed. This is a familiar concept for those used to ISA/TMG and often termed a ‘network behind a network’ scenario. The following articles by Tom provide some good (albeit old, but still largely valid) background information here:
Understanding ISA Firewall Networks (v1.1)
Advanced ISA Firewall Configuration: "Network Behind a Network" Scenarios
By following the above recommendations you should avoid the common problems caused by this topology and get your ‘network ducks in line’ before UAG errors occur…
Monitoring
The TMG Management console includes the Monitoring and Logs & Reports nodes which can be used to help with troubleshooting potential UAG issues. The Monitoring node provides an overview of TMG specific Alerts, Sessions, Connectivity Verifiers, Services and Configuration information, as shown below:

However, probably more useful is the ability to monitor real-time traffic flow to and from the UAG server. This can be achieved using the Logging tab located under the Logs & Reports node, as shown below:

The Logging tab provides the ability to view communications real-time and filter them accordingly to display only relevant information. If we click the Start Query link you will see all traffic that is currently being sent and received by the UAG server, as shown below:

The default filter criteria will provide all traffic information, as shown below:

With this tool available, we can now view traffic flow to try and determine potential configuration problems. For example if you are troubleshooting an issue related to access to a specific application server, you can define a filter using the Destination IP criteria, as shown below:

Or alternatively perhaps you are having LDAP authentication problems, so you can define a filter using the Protocol criteria, as shown below:

Additional information on TMG Monitoring can be found here.
By following the above recommendations you should gain better visibility of what is occurring ‘under the hood’ when troubleshooting UAG communication issues.
Systems Management
In order to manage Forefront UAG servers, it is often necessary to define firewall policy or system policy rules to permit communications between UAG and the appropriate management servers in question. This can be achieved using either custom access rules or the default system policy rules.
Forefront TMG system policy rules are a set of predefined access rules that control access between the Local Host network (the Forefront UAG server itself) and other networks. Some system policy rules are enabled by default to allow traffic that is necessary for managing the Forefront UAG environment.
An example of the default system policies is shown below:

By enabling the Show System Policy Rules option from the System Policy Tasks area, the rules can be seen in the firewall policy list for a more detailed view, as shown below:

An example customisation might involve enabling the default Remote Logging (SQL) system policy rule (which is disabled by default) and limiting the destination to a specific SQL Servers computer set as shown below:


For scenarios where the the default system policies do not cover systems management needs, it may be necessary to create custom access rules. These will likely be very specific to the environment, but will often include the following types of need:

  • Antivirus applications
  • Third-party system management applications (like LANDesk, HP Insight Manager etc.)
  • Remote control applications (like NetOp, VNC etc.)

Custom access rules can be created using the New Access Rule Wizard which is launched using the Create Access Rule link from the Firewall Policy Tasks area.
Due to the automated rule creation and placement process employed by UAG for TMG rules, it is recommended to place custom access rules at the very bottom of the firewall policy order, just above the Last Default Deny rule.
An example systems management custom access rule for a typical requirement is shown below:

Where possible, all systems management custom access rules should be defined using the principle of least privilege to minimise unnecessary TMG Local Host security exposure. This means using specific destinations, protocols and computer sets, as opposed to the use of ‘Any Outbound’, ‘Any Network’ or similar global objects.
Please Note: I am not currently 100% sure that the definition of custom access rules for systems management are fully supported, as the support boundaries document only specifically mentions ‘system policy’ rules. However, most enterprise organisation would often mandate this level of operational control for production deployments. Server Publishing
In general, the use of native TMG web or server publishing is not supported for Forefront UAG deployments. However, as discussed in the support boundaries document, the exceptions to the rule include some specific non-web Exchange client access protocols and also Office Communication Server. Based upon the protocols involved, these exceptions actually utilise the server publishing feature of TMG, as opposed to web publishing.
Please Note: In the case of the POP3 and SMTP protocols this also allows the application filters provided as part of TMG to be employed for better security control and protocol protection. TMG uses server publishing to process incoming requests to internal servers, such as Simple Mail Transfer Protocol (SMTP) servers, File Transfer Protocol (FTP) servers, Structured Query Language (SQL) servers, and others. Requests are forwarded downstream to an internal server, located behind the TMG computer.
Server publishing allows virtually any computer on your internal network to be published to the Internet. Security is not compromised because all incoming requests and outgoing responses pass through TMG. When a server is published by an TMG, the Internet Protocol (IP) addresses that are published are actually the IP addresses of the TMG computer. Users who request objects think that they are communicating with the TMG—whose name or IP address they specify when requesting the object—while they are actually requesting the information from the actual publishing server.
Server publishing rules determine how server publishing functions, essentially filtering all incoming and outgoing requests through the TMG computer. Server publishing rules map incoming requests to the appropriate servers behind the TMG computer. These rules will grant access dynamically, as specified, from Internet users to the specific publishing server.
By allowing the use of native TMG server publishing for Exchange, this also negates the need to use a UAG portal for ‘legacy’ mail services often used by email clients that cannot support WebDav or RPC-over-HTTP protocols.
Exchange client access publishing for POP3/IMAP/SMTP is supported natively within the TMG console using the Mail Server Publishing Rule Wizard which is launched using the Publish Mail Servers link in the Firewall Policy Tasks area. Follow the TMG wizards and you should be well on your way…
OCS publishing is not natively supported within the TMG console, but still makes use of TMG server publishing as detailed in the following article:
Securing OCS with ISA Server
Conclusion
Hopefully the above examples have helped define some of the TMG fundamentals that are specifically relevant for UAG deployments. More information on both TMG, and UAG, can be found in the official Microsoft documentation available here:
Forefront TMG Documentation
Forefront UAG Documentation





موضوعات مشابه: