Archive

Archive for the ‘Troubleshooting’ Category

Security Configuration Wizard for Forefront TMG 2010 and Windows Server 2008 R2 SP1

Security hardening and attack surface reduction is an important step in preparing a Forefront TMG 2010 firewall. To accomplish this task, the tool of choice is the Security Configuration Wizard (SCW). In one of my ISAserver.org articles I demonstrated how to use this tool to properly configure the underlying operating system to support the Forefront TMG 2010 firewall role. Since the native Windows SCW does not include support for the Forefront TMG role, the TMGRolesForSCW.exe utility included in the Forefront TMG Tools and SDK is required. This tool was released prior to service pack 1 for Windows Server 2008 R2 and does not include a template that works correctly out of the box. When you attempt to register the Windows Server 2008 R2 template on a system with SP1 installed you will receive the following error:

Command completed with error.
The parameter is incorrect.
Please check log file(s) under the following directory: 
%windir%\security\msscw\logs

To resolve this issue, create a copy of the template file SCW_TMG_W2K8R2_SP0.xml and name it SCW_TMG_W2K8R2_SP1.xml. Open this file with any text editor and navigate to the SCWKBRegistrationInfo node (line 2). Change the value of ServicePackMajorVersion from “0” to “1” and save the file. Register the template using the following command:

scwcmd register /kbname:TMG /kbfile:scw_tmg_w2k8r2_sp1.xml

Continue using the SCW to configure and apply a security template to your TMG firewall following the instructions in my ISAserver.org article.

Forefront TMG 2010 Web Proxy Auto Detect Fails

Recently I received a call from a customer who was trying to resolve an issue where all web proxy clients that were configured to use Web Proxy Auto Discovery (WPAD) with DNS suddenly stopped working. We began troubleshooting by confirming that the hostname WPAD resolved to the internal IP address of the Forefront TMG firewall, which it did correctly. Next we used a telnet client to confirm that the TMG firewall was listening on TCP port 80 (used by TMG for DNS WPAD clients) and indeed it was responsive. A scan of the event logs on the firewall turned up the following warning message:

The Web Proxy filter failed to bind its socket to 172.16.1.253 port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.”

Something was listening on TCP port 80, so we opened a command prompt and entered the following command in order to determine which process was listening on this port:

netstat –ano | findstr :80

Netstat was reporting that TCP port 80 was in a listening state and bound to the IP address 172.16.1.253. The process using this port was the System process (PID 4). This is unexpected, because the Forefront TMG web proxy service (wspsrv.exe) should be bound and listening on this port. Clearly this was a web service hijacking this port, so to find out more we entered the following command at a command prompt:

netsh http show servicestate

The output of this command revealed a valuable clue. Notice the registered URL below…

HTTP://172.16.1.253:80:172.16.1.253/REPORTSERVER_ISARS/

As it turns out, this customer had attempted to change the SQL Reporting Services Web Service URL. By assigning the Forefront TMG firewall’s internal IP address and changing the port to 80 in the Reporting Service Configuration Manager, this caused a conflict with the Forefront TMG web proxy filter, which requires TCP port 80 to provide WPAD for DNS.

To resolve the issue, the administrator chose a TCP port other than 80 and restarted the system.

Preparing Forefront TMG 2010 for Enterprise Workgroup Deployment

March 15, 2011 8 comments

Deploying Forefront Threat Management Gateway (TMG) 2010 in a workgroup (non-domain joined) enterprise array configuration can present a significant challenge to many administrators. This post isn’t meant to be a comprehensive TMG Enterprise Management Server (EMS) deployment guide, but I would like to share with you a few important tips that will hopefully make the process of creating an EMS-managed array a little easier.

Before Installing EMS

IP Addressing – Make certain that all basic IP connectivity is verified before installing any Forefront TMG 2010 services.

Name Resolution – Confirm that name resolution is working properly and that hostnames are being resolved to the correct IP addresses. Be sure that these IP addresses are assigned to the Internal network interface of the EMS and each array member.

Certificates – The EMS will require a machine certificate, and each array member should trust the Certificate Authority (CA) that issued this certificate. It is recommended that this certificate be issued by your internal private CA and not a public third-party CA. The certificate should be for server authentication and the common name on the certificate should be the FQDN of the host it is to be installed on. Be sure to install the root certificate and any intermediate certificates for the CA on the EMS and each array member. Make certain the certificate is issued with the option for the private key to be exportable.

Local Accounts – Identical (mirrored) local accounts should be configured on the EMS and each array member and be granted administrative rights for the Forefront TMG 2010 Enterprise.

After Installing EMS

Before joining a TMG firewall to an array, you can perform some preliminary tests to determine if certificate authentication between hosts is working correctly. To do this, open a PowerShell command window and enter the following commands:

import-module servermanager
add-windowsfeature rsat-adlds

Once complete, click Start | Run and enter ldp.exe. From the drop-down menu choose Connection, and then Connect…. For the server, enter the fully-qualified domain name (FQDN) of the EMS, specify port 2172, and then select the option to use SSL.

If certificate authentication is working correctly you will connect to the RootDSE. If it is not configured correctly you will receive a connection error.

To determine if user authentication is working correctly, select Connection from the drop-down menu and then Bind…. If you are currently logged on with the local mirrored account, select the option to Bind as currently logged on user, otherwise select Bind with credentials and enter the user and password of the mirrored account (leave the domain blank).

If configured correctly you will receive notification that you have been authenticated. If not, you will be notified that the logon attempt failed.

Once you’ve completed these steps you can proceed with configuring the TMG firewall to join the array. Be sure to specify the name of the EMS in exactly the same format as the certificate common name (preferably using the FQDN ).

Forefront TMG Performance Troubleshooting with PAL v2.x Part 2 – Data Analysis and Reporting

February 6, 2011 Comments off

In the first part of this two-part series we used PAL and Performance Monitor to collect data. In this second part I’ll demonstrate how to use PAL to analyze the data and generate a report.

Analyzing the Data

Once you’ve collected the necessary log data you are ready to analyze it using PAL. To begin, open the PAL tool, click Next or select the Counter Log tab, then choose the path to the log file collected using Performance Monitor.

Select Microsoft Forefront Threat Management Gateway for the threshold file and choose Next.

To accurately analyze the data, PAL needs to know specific details about the system where the log data was collected. Highlight and answer each question and choose Next.

Accept the default settings for Analysis Interval and All Counter Stats.

By default, PAL generates reports in HTML format and places them in the My Documents\PAL Reports folder. Here you can change the default file location and also select the option to generate reports in XML format.

Behind the scenes PAL leverages a complex PowerShell script to perform analysis and generate reports.

To perform the analysis and generate a report, click Finish. Optionally you can add the analysis job to the job queue or execute the analysis and restart the wizard with the same settings. You can also select the option to execute as a low priority process.

PAL begins analyzing the log data and once complete it generates a report in the format specified. You can view a sample report here.

The report is very detailed and includes alerts when a particular counter exceeds a predetermined threshold. The alerts are color coded to easily identify when a threshold has been exceeded. The report also includes a brief explanation of each counter, a graphical chart of the data analyzed, and statistical data relating to the counter.

PAL is a wonderful tool that greatly simplifies the process of analyzing Performance Monitor data. It is not, however, a magic wand that will solve all of your performance issues automatically. Although the tool provides a wealth of information in a clear and concise format, it is still up to the administrator to understand the data and ultimately determine how best to resolve the issue. PAL just makes that task much easier.

Forefront TMG Performance Troubleshooting with PAL v2.x Part 1 – Data Collection
Forefront TMG Performance Troubleshooting with PAL v2.x Part 2 – Data Analysis and Reporting

Forefront TMG Performance Troubleshooting with PAL v2.x Part 1 – Data Collection

February 6, 2011 4 comments

Troubleshooting performance issues on any system, especially a Forefront Threat Management Gateway (TMG) 2010 firewall can be a significant challenge for many administrators. The primary tool used for this task is the Windows Performance Monitor. This tool allows the administrator to monitor virtually every aspect of the operating system, applications, and hardware. However, deciding which objects and counters to monitor and how to interpret the data can be difficult.

That’s where Performance Analysis of Logs (PAL) comes in. Created by Microsoft Premiere Field Engineer (PFE) Clint Huffman, this free tool automates the analysis of logged data collected using Performance Monitor. PAL uses templates along with user input to analyze and report on the collected log information. It eliminates guesswork by highlighting counters that exceed predefined thresholds. PAL has been around for many years, but until recently has lacked support for Forefront TMG. Thanks to the effort and hard work by some Forefront PFE’s and CSS engineers, the recent release of PAL v2.0.7 now fully supports Forefront TMG.

PAL can be found at http://pal.codeplex.com/. It is available for 32- and 64-bit systems, and requires that Microsoft .NET Framework 3.5 SP1, Microsoft Chart Controls for .NET Framework 3.5, and PowerShell v2.0 be installed.

In this first part of a two-part series we’ll first look at how to use PAL to configure Performance Monitor to collect the necessary data. In the second part will use PAL to analyze the data and generate a report.

Collecting Data

Enabling private Performance Monitor counters is required to fully analyze performance on the Forefront TMG firewall. Enabling private Performance Monitor counters is accomplished be creating the following registry key on the Forefront TMG firewall:

HKLM\SOFTWARE\Microsoft\RAT\Stingray\Debug\FWSRV
"FWS_PRIVATE_PERFORMANCE_COUNTERS"=dword:00000001

Download .reg file here.

To begin collecting performance data on the Forefront TMG firewall, open the PAL tool and select the Threshold File tab, then click the drop-down box and choose Microsoft Threat Management Gateway.

Click Export to Perfmon Template File… and save the file.

On the TMG firewall, open the Performance Monitor, expand Data Collector Sets, and then right-click User Defined and choose New -> Data Collector Set.

Give the new data collector set a descriptive name, select the option to Create from a template, then click Next.

When the wizard prompts for which template to use, click Browse…, then select the PAL template file exported earlier.

Specify the folder where the logged data will be saved and click Finish.

Once complete, the new data collector set will appear. If you right-click the new collector set and choose Properties… you will see that it contains all of the necessary Performance Monitor objects and counters required to perform an in-depth performance analysis of the Forefront TMG firewall. Here you can also change parameters such as the log format (binary log format is recommend, however) and sample interval. You can also change file parameters such as the log file name, the file name format, and the logging mode (overwrite, append, or circular).

To start collecting data, right-click the data collector set and choose Start. Once the capture has started, you can right-click and select Stop to stop the capture.

You can also schedule data collection by right-clicking the data collector set and choosing Properties, clicking the Schedule tab, and then clicking Add.

You can also specify a stop condition that will cease data collection based on any number of different parameters including duration and size of the log file.

In the second part of this two-part series we’ll outline how to use PAL to analyze and generate reports of the Performance Monitor data.

Forefront TMG Performance Troubleshooting with PAL v2.x Part 1 – Data Collection
Forefront TMG Performance Troubleshooting with PAL v2.x Part 2 – Data Analysis and Reporting

A Word about Network Interface Port Speed and Duplex Settings

November 10, 2010 3 comments

When configuring network interface settings on a Forefront Threat Management Gateway (TMG) 2010 firewall, I strongly recommend that the port speed and duplex settings on all active network interfaces be manually configured. Although autonegotiation is typically enabled by default, and in most cases works without issue, I prefer to eliminate any possibility that a slower link speed or incorrect duplex setting is negotiated in error by configuring these settings explicitly.

Some believe you can configure one side of a link (either the host or the switch) manually and leave the other side set to autonegotiate. The theory is that the host set to autonegotiate will determine what settings the other side has configured and automatically choose those. This is not completely true and doesn’t work as expected. When one side of a link is set for autonegotiation and the other side is not (or doesn’t support it), a process called parallel detection takes place whereby the device that is configured to autonegotiate can determine the port speed of the other device, but it cannot determine the duplex settings and defaults to half duplex. Often this results in a duplex mismatch, which will cause extremely poor performance.

So, when configuring port speed and duplex settings, always remember that BOTH sides of the link should be configured identically. That is, if the switch is configured for 100Mbps/full duplex operation, the network interface on the TMG firewall should be configured the same. On some systems (mostly older ones), when attempting to change these settings, you might notice that there is no option to enable 1000Mbps (gigabit) at full duplex operation. The only available option is autonegotiate 1000Mbps.

Why is there no option to select 1000Mbps and full duplex? Because the designers of the 1000BASE-T specification (IEEE 802.3ab) made duplex autonegotiation mandatory when operating at 1000Mbps port speed over copper cabling. For this reason some network interface management software may limit your choices and not allow you to select this option. In my experience it appears that adherence to this mandate has been relaxed as most newer systems I have worked with now give you the option of configuring 1000Mbps and full duplex operation with copper cabling. If you have an older system and don’t have the option to specify 1000Mbps/full duplex on the network interface, I would recommend updating your network interface device drivers. If you still don’t have the option to specify 1000Mbps/full duplex you may need to replace the network interface card itself.

Fwengmon.exe and Forefront Threat Management Gateway (TMG) 2010

November 2, 2010 2 comments

For engineers performing advanced troubleshooting on TMG, you have likely noticed that fwengmon.exe, a utility that you used with previous versions of ISA, no longer functions with TMG.

Not to worry! This detailed information is readily accessible using netsh.exe in the tmg context. The following is a list of common commands and their fwengmon.exe equivalents (where applicable):

To view creation objects, active sessions, NLB hook rules, NLB server assigned ranges, and dynamic and persistent allowed ranges:

netsh tmg show all

To view connections only (fwengmon.exe /session or /s):

netsh tmg show connections

To view detailed information about a specific connection (fwengmon.exe /s <ID>):

netsh tmg show connections <connection_number>

To view firewall creation elements (fwengmon.exe /creations or /c):

netsh tmg show creations

Note: You can sort and filter output from show connections or show creations by source IP address, source port, destination IP address, destination port, or protocol using the sort and filter parameters (fwengmon.exe /organize or /o, or fwengnmon.exe /filter or /f). You can also limit the number of connections or creations displayed using the display parameter. Type netsh tmg show connections ? or netsh tmg show creations ? for more information.

To show NLB hook rules (fwengmon.exe /querynlb or /n):

netsh tmg show nlbhookrules

To view packets held in kernel mode:

netsh tmg show holdpackets

To view packets held in user mode:

netsh tmg show usermodepackets

To view global firewall engine driver settings:

netsh tmg show global

To specify a temporary address range to exempt from firewall filtering (fwengmon.exe /allow or /a):

netsh tmg add allowedrange <beginning_ip> <ending_ip>

To specify a permanent address range to exempt from firewall filtering (fwengmon.exe /allow or /a):

netsh tmg add allowedrange <beginning_ip> <ending_ip> persistent

Note: netsh tmg add allowedrange allows all traffic to and from hosts within the IP address range specified to bypass stateful firewall inspection completely. It should be used for troubleshooting purposes only.

To delete a temporary address range (fwengmon.exe /noallow):

netsh tmg delete allowedrange id=<id>

To delete a permanent address range (fwengmon.exe /noallow):

netsh tmg delete allowedrange id=<id> persistent