Archive
Forefront TMG 2010 End of Life Statement
Today, Microsoft announced the Forefront TMG 2010 product will be discontinued. Microsoft will continue to provide mainstream support for TMG until April 14, 2015, and extended support until April 14, 2020. The Forefront TMG 2010 Web Protection Services (WPS) will be discontinued on December 31, 2015. Beginning on January 1, 2016, Web Protection Services (URL filtering, virus/malicious software scanning, and Network Inspection System) will continue to function but will no longer receive updates.
The end of life for Forefront TMG 2010 comes as part of sweeping changes made to the entire Forefront protection suite of products. In addition to ending development of Forefront TMG 2010, Microsoft also announced that Forefront Protection for Exchange (FPE), Forefront Protection for SharePoint (FPSP), Forefront Security for OCS (FSOCS), and Forefront Protection Server Management Console (FPSMC) are all being discontinued. Forefront Online Protection for Exchange (FOPE), which has been a part of Office 365, is being renamed Exchange Online Protection.
Looking ahead, Forefront Unified Access Gateway (UAG) 2010 and Forefront Identify Manager (FIM) 2010 R2 both have current roadmaps and will continue to be developed, although it is likely that they will not continue under the Forefront brand name.
Forefront TMG 2010 Protocols and Ports Reference
When deploying Forefront TMG 2010 as a forward or reverse proxy, many organizations will place their TMG firewalls in a perimeter or DMZ network to provide an additional layer of protection for their proxies. When deployed in this manner, configuring perimeter firewalls to allow proper communication to and from the Forefront TMG firewall can be challenging. Although the Service Overview and Network Port Requirements for Windows document on TechNet includes information about ISA server (which also applies to TMG) it includes all protocols and ports used by TMG in all deployment scenarios. This can be confusing when you simply want to allow TMG firewalls in a perimeter network to communicate with an Enterprise Management Server (EMS) on the internal network, or simply manage a TMG firewall in a perimeter network from a management workstation on the internal network. Opening all of the ports listed in the Microsoft KB article mentioned above would be unnecessary and would violate the principle of least privilege, which dictates that only the specific ports required for communication should be opened.
Note: This reference covers typical TMG configurations and may not include all protocols and ports required for every deployment scenario. For example, if you are using RADIUS or RSA for authentication, have configured connectivity verifiers or a remote SQL server, or have deployed Forefront TMG 2010 for Exchange integration, each of these configurations will require additional perimeter firewall access. Also, don’t forget that your perimeter firewalls will need to allow access to the protocols and ports required for the services you are accessing/publishing through Forefront TMG 2010.
For reference, here are the protocols and ports required for specific, common Forefront TMG 2010 deployment scenarios:
EMS to TMG
TCP 135, 10000-65535* – RPC
TCP 3847 – MS Firewall Control
TMG to EMS
TCP 445 – CIFS
UDP 445 – CIFS
TCP 2171 – MS Firewall Storage (domain-joined only)
TCP 2172 – MS Firewall Storage Secure (workgroup mode only)
TCP 3847 – MS Firewall Control
TMG to DCs
Domain joined…
TCP 88 – Kerberos
UDP 88 – Kerberos (send receive)
UDP 123 – NTP
TCP 135, 49152-65535* – RPC
TCP 389 – LDAP
UDP 389 – LDAP
TCP 445 – CIFS
UDP 445 – CIFS
TCP 3268 – LDAP Global Catalog
Non domain-joined…
TCP 389 – LDAP (required only for pre-authentication in reverse proxy scenarios)
TCP 636 – LDAPS (required only for pre-authentication in reverse proxy scenarios)
TMG to DNS
TCP 53 – DNS (send receive)
UDP 53 – DNS
Primary EMS to Replica EMS
TCP 135, 49152-65535* – RPC
TCP 2173 – MS Firewall Storage Replication
Replica EMS to Primary EMS
TCP 135, 49152-65535* – RPC
TCP 445 – CIFS
UDP 445 – CIFS
TCP 2171 – MS Firewall Storage – domain-joined only
TCP 2172 – MS Firewall Storage (Secure) – workgroup mode only
TCP 3847 – MS Firewall Control
Web Proxy Client to TMG
TCP 80 – HTTP (WPAD only)
TCP 8080 – HTTP Proxy
Firewall Client to TMG
TCP 80 – HTTP (WPAD only)
TCP 1745 – Firewall Client Control Channel
UDP 1745 – Firewall Client Control Channel
TCP 1024-65535 – All high ports**
UDP 1024-65535 – All high ports**
Management Workstation to TMG
TCP 135, 10000-65535* – RPC
TCP 2171 – MS Firewall Storage – Domain mode only
TCP 2172 – MS Firewall Storage (Secure) – Workgroup mode only
TCP 3847 – MS Firewall Control
*The default dynamic port range for Windows Server 2008 R2 is 49152-65535. When TMG is installed this setting is changed to 10000-65535. This does not apply to TMG EMS, however. RPC can be configured to use a smaller range of dynamic ports, if necessary. For more information, please see Microsoft KB 154956.
**The Forefront TMG 2010 Firewall Client is designed to operate without a firewall between itself and the TMG firewall. It is highly recommended that you avoid this design whenever possible. If this is unavoidable, all TCP and UDP high ports will have to be opened, as the TMG Firewall Client control channel utilizes random high ports and cannot be restricted as RPC can.
Addressing Security Issues with PPTP VPN in Forefront TMG 2010
At the recent DEFCON hacking conference, security researchers demonstrated a method to crack the MS-CHAPv2 authentication protocol with a 100% success rate. MS-CHAPv2 is used as the default authentication method for remote access VPN in Forefront TMG 2010.
With the public availability of tools to automate the cracking process, PPTP communication using MS-CHAPv2 should be considered unencrypted. There are two options available to mitigate this concern: disable MS-CHAPv2 and enable EAP with PPTP, or disable PPTP and switch to a more secure remote access VPN protocol such as L2TP/IPsec or SSTP. Enabling EAP requires the use of smart cards or certificates for authentication which makes implementation more challenging. SSTP is an excellent option as it leverages SSL/TLS to protect the MS-CHAPv2 authentication process. However, SSTP is only supported on Windows Vista SP1 and later clients. L2TP/IPsec is another good choice, and although it does support certificates it can also be configured using a pre-shared key. If long, complex passwords are used and care is taken to ensure that the password is well protected, it can provide a secure remote access solution.
Controlling Access to File Shares with Forefront TMG 2010
Consider a scenario in which you have an IIS server located in a perimeter network protected by Forefront TMG 2010. The server is published to the Internet and is used to display product information for your company. Web content developers on your internal network need to have access to file shares on the IIS server to upload new web content. To facilitate this access you create an access rule to allow CIFS access to the IIS server. For security reasons you decide to restrict access to members of the Web Content Developers domain group. In addition, your workstations have the Forefront TMG Firewall Client installed. The access rule looks like this:
When users attempt to map a drive to the file share on the web server they receive the following error message:
System error 67 has occurred. The network name cannot be found.

In addition, the Forefront TMG 2010 firewall log indicates the following:
Denied Connection Log Type: Firewall Service Status: The action cannot be performed because the session is not authenticated.

At this point you might be puzzled because you have the Forefront TMG Firewall Client is installed on the workstation. TMG Firewall Client communication is always authenticated, so why does the firewall log indicate otherwise? The answer is simple. The Forefront TMG 2010 Firewall Client is a Layered Service Provider (LSP) that listens for Winsock calls made by the operating system and applications. Any Winsock calls made for resources on a remote network will be transparently delivered to the proxy server by the Firewall Client. However, CIFS communication does not use Winsock, so the TMG Firewall Client does not handle this traffic. As such, the network requests are delivered to the Forefront TMG firewall as SecureNAT requests. Since the rule in question requires authentication, and SecureNAT traffic cannot be authenticated, the firewall appropriately denies the traffic and the request fails.
You can resolve this issue by removing authentication on the access rule and controlling access on the file share itself. If you want to enforce user and group authentication at the firewall, consider using another protocol such as FTP.
For more information about the Forefront TMG 2010 Firewall Client and CIFS connections, please review Microsoft Knowledge Base article 913782.
Fastvue Enhanced Reporting for Forefront TMG 2010
Recently I had the pleasure of reviewing the Fastvue Dashboard product for Forefront TMG 2010 at ISAserver.org. Fastvue is a real-time dashboard that integrates with Forefront TMG to provide a nearly instantaneous view of traffic being controlled by your TMG firewall. Although the real-time dashboard is a nice feature, if you’ve spent any time at all with Forefront TMG 2010’s native reporting tools you know that TMG is severely lacking in this area. A major limitation of Forefront TMG 2010’s in-box reporting is that the reports are generated using summarized data. Data summarization occurs only once daily, so reports can be lacking essential information if you are looking for recent activity. In addition, the native reports are static and one-dimensional. If a report reveals something interesting that you want to know more about, creating and generating a new report is required.
Thankfully the good folks at Fastvue recognized these shortcomings and have addressed many of these issues with their latest release. Fastvue v2.0 now includes full historical reporting capabilities, with detailed company overview and user investigation reports that can be shared via e-mail. Reports can also be scheduled to run automatically. The reports are highly interactive, allowing the administrator to dynamically drill down to generate more granular reports in an instant.

The current version of Fastvue is priced at $395.00 per TMG firewall. The newest version will be priced at $795.00 per server. However, for a limited time, readers of my blog can purchase Fastvue v1.0 for the current price and receive a free upgrade to v2.0 when it is released. Click here to download a trial of the software and to take advantage of this offer!
Hotfix Rollup 1 for Forefront TM 2010 SP2 Now Available
A hotfix rollup for Forefront TMG 2010 SP2 is now available. The hotfix rollup resolves several reported issues with TMG, including:
KB2654016 – A client may be unsuccessful in accessing a Java SSO application published to the web by Forefront TMG 2010
KB2653703 – “Error: Subreport could not be shown” error message in the User Activity or Site Activity report in Forefront TMG 2010
KB2654585 – UDP packets may become backlogged when you increase the “maximum concurrent UDP sessions per IP address” setting in Forefront TMG 2010
KB2624178 – Forefront TMG 2010 administrators may be unable to generate reports
KB2636183 – Both sides of a TCP connection are closed when the client or remote application half-closes the TCP connection in Forefront TMG 2010
KB2653669 – Summary information for the Top Overridden URLs table and for the Top Rule Override Users table display incorrect information in Forefront TMG 2010
KB2617060 – Forefront TMG 2010 enables L2TP site-to-site connections in RRAS
KB2655951 – Japanese characters in the subject line of an Alert email message are not readable in the Japanese version of Forefront TMG 2010
KB2654068 – “The Web Listener is not configured to use SSL” warning message may occur when you configure a Web Listener to use a valid SSL certificate in Forefront TMG 2010
KB2654193 – You receive a “Bad Request” error message when you try to access Outlook Web App published by Forefront TMG 2010
KB2654074 – String comparison may become case-sensitive when you published a website using Forefront TMG 2010
KB2658903 – Forefront TMG 2010 firewall service (wspsrv.exe) may crash frequently for a published website secured by SSL after you install Service Pack 2.
Hotfix rollup 1 for Forefront TMG 2010 SP2 can be downloaded here. After applying this update, the new Forefront TMG 2010 build number will be 7.0.9193.515.
TrainSignal Forefront TMG 2010 Training
Are you looking for Forefront TMG 2010 training? If so, take a look at TrainSignal’s Forefront TMG 2010 training package. This is a comprehensive video training course that includes 8 hours of video instruction over 21 modules. Scott Lowe does an excellent job of delivering the course, which is available online and on disc. I had the privilege of serving as the technical reviewer for this video training series, so I can assure you the material is exceptional.
If you are planning to deploy Forefront TMG 2010 in the future, or perhaps you are considering a migration from previous versions of ISA server to Forefront TMG 2010, the TrainSignal Forefront TMG 2010 video training series is an excellent investment. Check it out now!
Error 0xc0040431 When Creating a Forefront TMG 2010 Enterprise Array
When attempting to join a Forefront TMG 2010 enterprise edition firewall to an Enterprise Management Server (EMS) managed array, you may encounter one of the following error messages:
The operation failed. Error: 0xc0040431 Forefront TMG Services failed to start after array join or an array disjoin. Check alerts, fix the configuration, and attempt to restart the services.

The operation failed. Error: 0xc0040410 The file cannot be imported because the enterprise management mode is 2010SP1 in the exported file and 2008-only in the stored configuration.

You may also encounter one of the following error messages when attempting to create a standalone array with two or more Forefront TMG 2010 enterprise edition firewalls:
The operation failed. Error: 0x80004002 No such interface supported

The operation failed. Error: 0xc0040410 The file cannot be imported because the enterprise management mode is in the exported file and in the stored configuration.

Any of these errors can occur when you attempt to join a pre-SP2 Forefront TMG 2010 firewall to an EMS-managed array running Forefront TMG SP2, or when you attempt to create a standalone array with one node running Forefront TMG SP2 and another node running SP1.
To resolve this issue, make certain that Forefront TMG 2010 firewalls are all at the same service pack and update level before joining an EMS-managed array or creating a standalone array. For information about determining which version of ISA or TMG is installed, refer to one of the following blog posts:
http://tmgblog.richardhicks.com/2010/10/11/how-to-determine-tmg-version/
http://tmgblog.richardhicks.com/2010/12/03/more-about-determining-tmg-version-numbers/
For a documented reference of ISA and TMG build numbers, click here.
Forefront TMG 2010 Configuration Change Description Survey
When making changes to the Forefront TMG 2010 firewall, by default the administrator is prompted to enter a description of the configuration changes made before they are applied. For those TMG administrators that use this facility, what kind of information do you put in this change description box? A verbose explanation of changes made? Details about why the change was made? Your name, network ID, or initials? Is it helpful to provide reference to a help desk ticket or a change request?
Tell me how you use this feature and what kind of information you typically provide by commenting on this post. I’ll approve the most interesting and useful ones as they come in. Thanks in advance for participating!

Forefront TMG 2010 Protocol Direction Explained
When reviewing the configuration of a pre-defined protocol or creating a custom protocol on the Forefront TMG 2010 firewall, many new (and sometimes even veteran) firewall administrators can be confused by the protocol direction. The correct configuration of the protocol direction is essential for proper firewall operation, but there are times when it can be somewhat unintuitive. In this post I’ll provide some clarification.
TCP
For TCP protocols the direction can be specified as either inbound or outbound.

For access rules, protocol direction is configured as outbound. Traffic flows outbound from the source to the destination. This is true even when creating an access rule to allow traffic inbound to the Forefront TMG 2010 firewall itself. It sounds counterintuitive, but the TCP protocol direction for access rules allowing access to the Local Host network should still be outbound. Why? Again, because traffic flows outbound form the source to the destination, in this case the TMG firewall’s Local Host network. If, in this case, you were to configure the protocol direction as Inbound (intuitively, inbound to the TMG firewall) it will not work.
For publishing rules, protocol direction is configured as inbound. Traffic flows inbound from the source to the published service on the Forefront TMG 2010 firewall. Pre-defined server publishing protocols include the “server” suffix, as shown here:

UDP
For UDP protocols the direction can be specified as either Receive, Receive Send, Send, or Send Receive.

For access rules, protocol direction is configured as Send. Traffic is sent from the source to the destination. If a response is expected then the protocol direction is configured as Send Receive. This is required because UDP is connectionless and the return traffic would otherwise be denied by the TMG firewall.
For publishing rules, protocol direction is configured as Receive. Traffic is received by the TMG firewall from the source to the published service on the Forefront TMG 2010 firewall. If a response is expected then the protocol direction would be configured as Receive Send.
IP and ICMP
For IP and ICMP protocols the direction can be specified as either Send or Send Receive.

IP and ICMP protocol definitions are only supported for access rules, so protocol direction is configured as Send. As with UDP, IP and ICMP are connectionless and if a response is expected then the protocol direction is configured as Send Receive.






