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.
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.
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:
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.