Archive
A Word about Network Interface Port Speed and Duplex Settings
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
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
TMG and IANA Unallocated Reserved Networks
Recently the engineers at Celestix UK brought an interesting issue to my attention. They were working with a customer to configure TMG to protect an internal network using the address space 192.0.0.0/24. When attempting to assign an IP address from this network to the Internal network interface of the TMG firewall they would receive the following error:
As it turns out, the 192.0.0.0/24 network is IANA reserved and not allocated (which is different than reserved allocated networks like RFC 1918 private address ranges, APIPA, loopback, multicast, etc.). This was news to me! As we discovered, you cannot configure any network interface on the TMG firewall using an address from any unallocated reserved network. Interestingly enough, my good friend Ed Horley pointed out there are many more IANA reserved networks that I was completely unaware of. You can find more information about those networks here.
If you have to configure a TMG firewall to protect an unallocated reserved network, your only options are to readdress the network using an allocated address range or place a router in front of TMG.
Forefront Threat Management Gateway (TMG) and Windows Server 2008 Networking Scalability Features
Several years ago, Microsoft released the Scalable Networking Pack (SNP) for Windows Server 2003 SP1. The SNP included enhancements to the operating system’s networking stack to improve scalability and increase performance. Later the SNP features were included in Windows Server 2003 SP2. Veteran ISA firewall administrators will recall that the SNP adversely affected the operation of ISA, particularly when Network Load Balancing (NLB) was enabled. Since these features were enabled by default, disabling them after installing the SNP or Windows Server 2003 SP2 on an ISA firewall was a requirement. This was accomplished by modifying registry keys or installing a hotfix that disabled the SNP features.
Today, the networking stack in Windows Server 2008 and Windows Server 2008 R2 both include the capabilities originally introduced with the SNP. Instead of modifying registry keys to enable/disable those features as we did in Windows Server 2003, they are now managed using netsh.exe. To view these parameters, enter the following command:
netsh interface tcp show global
As you can see, SNP components such as receive-side scaling, chimney offload, and NetDMA are enabled by default. Thankfully TMG is now fully compatible with all of the scalable networking features. There is no need to disable them unless you have a specific requirement to do so.
Wireshark Network Analysis Book – Available for Pre-Order
A comprehensive reference dedicated to the ubiquitous Wireshark protocol analyzer, authored by the foremost expert in protocol analysis and Wireshark, Laura Chappell, is now available for pre-order. Due to be released on March 29, 2010, you can view sample pages by visiting wiresharkbook.com. Be sure to visit wiresharktraining.com and chappellseminars.com for additional training and reference material.
NMap 5.21 Released
NMap, the venerable network security scanner, has recently been updated. NMap 5.21 includes a ton of new enhancements. If you are new to NMap or would simply like to enhance your skills I would strongly encourage you to read the NMap Network Scanning book, written by the author of NMap.
Remote Performance Monitoring and Forefront Threat Management Gateway
Recently I encountered an issue when after installing and configuring Microsoft Forefront Threat Management Gateway 2010 (TMG) I was unable to gather performance data remotely. I found this puzzling because I was able to perform other management tasks such as connecting remotely with RDP and the TMG management console without issue. Since my management workstation was a member of the Remote Management Computers network object for the array, I assumed that I would have sufficient access to perform this task. Looking at the access logs revealed something interesting; traffic on TCP port 445 from my management workstation was being denied.
Upon reviewing the system policy I noticed that the Remote Performance Monitoring policy was not enabled. I’ve never had to enable this rule in the past to collect performance data remotely, but I tried enabling it anyway just for good measure.
Enabling this system policy rule did not resolve my issue, and the access log still showed my CIFS traffic being denied. A closer look at this rule shows that only NetBIOS protocols were included, not CIFS.
Under normal circumstances, enabling this rule isn’t required if you have the Allow remote management from selected computers using MMC system policy rule enabled (it is enabled by default). What made this situation unique, and ultimately caused the communication failure, was that NetBIOS over TCP/IP was disabled on all network interfaces.
To understand why monitoring performance remotely fails when NetBIOS over TCP/IP is disabled requires an understanding of Server Message Block (SMB) communication. SMB is an application-layer protocol that uses TCP for transport layer communication. In Microsoft operating systems prior to Windows 2000, all SMB communication took place over NetBIOS, which in turn ran on top of TCP/IP using the familiar TCP port 139. Beginning with Windows 2000, SMB runs directly on top of TCP/IP using TCP port 445. In Windows 2000 and later, the default behavior of SMB communication is to attempt to communicate directly over TCP/IP using TCP port 445 first, then if there is no response, an attempt to use NetBIOS over TCP/IP is made using TCP port 139 (provided NetBIOS has not been explicitly disabled). The performance monitor utility (perfmon.exe) communicates in exactly this way. Since NetBIOS over TCP/IP was disabled, communication only takes place over TCP port 445. In the absence of an access rule allowing Microsoft CIFS (TCP) inbound to the local host, the communication fails.
This issue can be resolved in several ways. First, enabling the Allow remote management from selected computers using MMC or the Allow remote performance monitoring of Forefront TMG from trusted servers system policy rule and enabling NetBIOS over TCP/IP on the network interface will resolve the issue. Since disabling NetBIOS over TCP/IP was required by security policy in this case, creating an access rule allowing Microsoft CIFS (TCP) inbound to the local host from Remote Management Workstations was the best choice.
Another option is to enable the Allow access from trusted servers to the local configuration storage server system policy rule, as this rule allows Microsoft CIFS (TCP) protocol inbound to the local host.
This may not be desirable because the rule includes additional protocols that aren’t required for remote performance monitor data collection, and increases exposure of services running on the TMG firewall needlessly.
Wireshark v1.2.3 Now Available!
Wireshark just announced the availability of Wireshark v1.2.3. Included in this release is version 4.1.1 of WinPcap that now works with Windows 7! Download your copy today!
Troubleshooting Basic HTTP Connectivity Using VBScript
As a follow up to my last blog post I wanted to share with you a way to perform basic HTTP connectivity testing using VBScript. Using the GetAllResponseHeaders method of the XMLHTTP object we can easily retrieve and display response headers returned by a web server. The VBScript code looks like this:
Option Explicit
Dim HTTP, Site
Site = InputBox(“Enter site name:”, “Get All Response Headers”)
Set HTTP = WScript.CreateObject(“Microsoft.XMLHTTP”)
Call HTTP.Open(“HEAD”, “http://” & Site, False)
Call HTTP.Send()
MsgBox HTTP.GetAllResponseHeaders(), vbInformation, “Response Headers for ” & Site
Set HTTP = Nothing
Copy the code above to a text file and save it with a .vbs extension. Double-click on the file and you will be prompted to enter a web site to test.
Enter the name of the web site to test and choose ‘Ok’. The script will send a request to the web server and display the response headers returned.
Admittedly this code is very rudimentary, but it is a simple and effective way to troubleshoot HTTP connectivity issues. If you are interested in something similar that has many more features, including the ability to use specific HTTP commands, perform logging, use a proxy server, specify a USER AGENT string and much more, visit Jim Harrison’s ISATools.org and download his very powerful HTTP_TEST VBScript.
Troubleshooting Basic HTTP Connectivity Using A Telnet Client
In my last blog post I demonstrated how to use the Windows telnet client to perform basic network connectivity troubleshooting. In this post I will demonstrate how to use the telnet client to interactively perform basic HTTP troubleshooting.
Note: This post assumes that you have a fundamental understanding of the HTTP protocol. If you are not familiar with HTTP and would like to learn more, there are some excellent books on the subject available. Two books that I recommend are HTTP – The Definitive Guide and the HTTP Pocket Reference, both from O’Reilly Books.
To begin, open a command prompt and enter the command telnet. This will bring up a telnet command prompt.
Notice that the escape character is CTRL+]. We’ll need to know this later. Next, enter the command set localecho. This command allows us see the text that we type in the command window.
To establish a connection to a web server on the default port, the command syntax is open <IP address, FQDN, or hostname> <port>.
For example…
open intranet.celestix.net 80
After you enter the open command and hit enter, it is not readily apparent that a connection has been made to the web server. That’s because the cursor immediately jumps to the upper left corner of the command window.
Before entering commands, hit the enter key a few times to bring the cursor to a clear area in the window.
Now that we have established a connection, we are ready to issue some basic HTTP commands to the web server. Let’s begin by retrieving the default web page for the site intranet.celestix.net. Although a full-featured HTTP client will send many request headers to a web server to retrieve content, the RFC specifies that only the HOST header is mandatory for HTTP 1.1. First we will send a GET command requesting the default page, then we will provide the HOST header to let the web server know which web site we are requesting content from (this is required because the web server may be hosting multiple web sites using the same IP address).
To retrieve the default page from intranet.celestix.net, enter the following commands:
GET / HTTP/1.1
HOST: intranet.celestix.net
These commands are case sensitive! Be sure to enter them exactly as shown above. After entering the HOST information, hit enter twice to send the commands to the web server. If successful, the web server will respond with the requested content.
Enter the escape command sequence CTRL+] to return to the telnet command prompt.
Additional Examples
Instead of retrieving the content of the web page, we could request that the web server send response headers only. This can be accomplished by entering the following commands:
HEAD / HTTP/1.1
HOST: intranet.celestix.net
If successful, the web server will send only the response headers and not the content of the web page itself.
Although somewhat useful in troubleshooting basic HTTP communication, the telnet client isn’t the best tool to use. As you will quickly see, the telnet client will not allow you to backspace if you make a typo entering a command. The advantage of using the telnet client is that it is installed on most Windows operating systems by default. Thankfully, a much more robust and feature rich tool is available from Microsoft. WFetch is a GUI utility that allows you to issue many different commands to the web server and includes support for multiple authentication methods. It includes the flexibility to manipulate headers and provides the ability to direct communication through a proxy server. If you are performing advanced troubleshooting or want to learn more about HTTP communication, you can find out more about using WFetch here.
Connect
Richard Hicks' Forefront TMG Blog 