Archive
Scalable Networking Pack and the ISA Firewall
If you’ve spent any time at all looking at alerts on a Microsoft ISA firewall, you have no doubt seen the following alert:
“The Windows Server 2003 Scalable Network Pack, which is included in Windows Server 2003 Service Pack 2, is enabled. Some ISA Server features will not work properly if a network adapter installed on an ISA Server computer supports and uses the Scalable Network Pack features. For more information, see the Microsoft Knowledge Base article 948496. If you do not have a network adapter that supports the Scalable Network Pack features, you can disable the Windows Server 2003 Scalable Network Pack Enabled alert.”
What does this mean? What is the Scalable Network Pack? Why are we being alerted about it? How did it get installed? Well, let me answer some of those questions for you!
The Microsoft Windows Server 2003 Scalable Networking Pack (SNP) provides support for network acceleration and offloading technologies available in today’s advanced network interface adapters to increase performance and scalability. It was made available as an update to Microsoft Windows Server 2003 SP1, and was later included in Windows Server 2003 SP2. The Scalable Networking Pack consists of the following three new features:
TCP Chimney Offload – Provides for automated, stateful offload of TCP processing to a network adapter that includes a TCP offload engine (TOE). For certain types of network communication (typically large file transfers) TCP Chimney Offload reduces CPU overhead by offloading network packet processing tasks such as packet segmentation and reassembly to the network adapter.
Receiver-side Scaling – Enables the processing of inbound networking traffic to be shared across multiple CPUs. Applications that rely heavy on inbound network communication that run on a multiprocessor system can benefit from Receiver-side Scaling.
NetDMA – Enables memory management efficiencies through direct memory access (DMA), provided the server supports this.
All of these features are wonderful, and have the ability to dramatically increase throughput and substantially reduce processor utilization for network intensive applications. At first you might think that these features would be beneficial to the ISA firewall, but unfortunately, they are not. TCP offloading is designed primarily for large file transfers, and provides little benefit for short-lived conversations that are typical of network traffic handled by the ISA firewall. There are also some incompatibilities as well. For instance, Receiver-side Scaling is incompatible with both NAT and NLB, both commonly configured on an ISA firewall.
It is for these reasons that you will see this alert generated by the ISA firewall, and as a best practice you should disable these features to prevent unexpected behavior. Microsoft Knowledge Base article 948496 includes an update to turn off the default SNP features, as well as instructions on how to disable these features by editing the registry.
RunAs Radio Appearance
Recently I was invited to be a guest on RunAs Radio, a weekly Internet audio talk show for IT professionals working with Microsoft products. I had the opportunity to chat with hosts Richard Campbell and Greg Hughes about the Microsoft ISA firewall, the forthcoming release of Threat Management Gateway, as well as the Celestix MSA security appliance. RunAs Radio has been around since 2007 and has featured guests such as Mark Minasi, Clint Huffman, Steven Choy, Brian Komar, and Steve Riley, just to name a few.
Scripting with Microsoft ISA Server 2006
One of my very favorite things about the Microsoft ISA firewall is the fact that you can do just about anything by leveraging the ISA Server administration COM object. Through scripting you can alter the configuration, automate repetitive or complex tasks, gather session information, import and export data, and much more. Here is a short example of a script that will display the version information for the ISA software you are running:
Option Explicit
Dim Root, Server
Set Root = CreateObject(“FPC.Root”)
Set Server = Root.GetContainingServer
WScript.Echo Server.ProductVersion
Set Server = Nothing
Set Root = Nothing
If you are interested in scripting the ISA COM object at all, ISA Server Administration Scripting on MSDN is a great place to get started. There you will also find a complete reference to all of the ISA related COM objects, as well as some sample scripts. There are some great web sites that have some excellent ISA scripts you can download and use as is. Jim Harrison’s ISATools.org is an excellent resource, as is Jason Fossen’s ISAScripts.org.
ISA Firewall Client Command Line Options
The Microsoft ISA Server Firewall Client is a wonderfully amazing piece of software that allows you to very granularly control network communication on hosts which it is installed (you can download it here). If you are not familiar with the Firewall Client, it is a software component that can be installed on Windows hosts that allows you to proxy any TCP or UDP based communication. There is no need to configure individual applications to work with the Firewall Client. It is a layer service provider that transparently intercepts Winsock calls and if the destination is remote, the Firewall Client sends that communication to the ISA firewall. Your routing infrastructure becomes transparent to your clients, and you gain the ability to enforce user and group based access control. Best of all, the Firewall Client logs not only the user name for each request, but the application that made the request as well. Very powerful stuff!
Troubleshooting Firewall Client communication can sometimes be difficult, however. Thankfully enough, there is a command line utility included with the Firewall Client that makes that job much easier. If you navigate to the ‘Program FilesMicrosoft Firewall Client 2004’ folder you will find a program called ‘fwctool.exe’. This tool allows you to do things like enable and disable the client software itself:
fwctool.exe enable
fwctool.exe disable
It can also be used to display the version of the Firewall Client software you currently have installed:
fwctool info
You can alter the configuration of the Firewall Client:
fwctool SetManualServer
fwctool SetAutoDetectServer
And you can display the current configuration information as well:
fwctool PrintConfig
fwctool PrintServerConfig
fwctool PrintUserConfig
fwctool PrintGlobalConfig
The Firewall Client has the ability to automatically configure the web browser that is installed on the workstation. This option can be displayed, enabled, or disabled from the command line as well:
fwctool DisplayBrowserConfig
fwctool EnableBrowserConfig
fwctool DisableBrowserConfig
You can also verify connectivity to the ISA firewall by using the PingServer option:
fwctool PingServer
I absolutely love the Firewall Client because of its power and flexibility. Having the ability to leverage strong user and group based authentication on ALL TCP and UDP protocols is fantastic. Look for more posts here on my blog about the Firewall Client and how to troubleshoot it as well as to leverage it.
ISA Behind a Cisco ASA?
Several people have written to me in response to my earlier blog post ‘HTTP 2.0 Specification?‘ asking why I would have my ISA firewall behind a Cisco ASA. The answer is simple: enhanced security! I am following a long standing security best practice by implementing security in layers; defense in depth. Now, it’s not that the ISA firewall isn’t totally and completely capable of acting as an edge firewall, because it most certainly is. In this case though, I have elected to use an ASA as my edge firewall because I don’t need any real intelligence there. All I want is to do some very simple packet filtering here; basically just filtering out the bulk of the noise from the Internet and allowing my internal ISA firewall, with its advanced deep application layer inspection capabilities and granular user and group based access controls to do the important network communication inspection.
In addition to enhanced security, there are some other benefits to using the ASA (or another firewall) at the network edge. If someone were to circumvent the access controls that are in place on that edge firewall, they would not be able to use those same methods of exploitation on the ISA firewall. If I practice security in layers but deploy the same model firewall at each layer, an attacker can use the same method used to bypass my internal firewalls as they used to bypass my edge firewall.
An additional benefit by using another firewall at the network edge is that by squelching ‘Internet noise’, the logs on the ISA firewall become much more meaningful. It allows me to find important information much more quickly than having to sift through mountains of data this is mostly port scans and probes that occur constantly on the public Internet. This also frees up resources on my ISA firewall that are better put to use on inspecting important traffic.
HTTP 2.0 Specification?
I wanted to share with everyone what I thought was an entertaining issue that was brought to my attention by one of our (Celestix) support engineers recently. The issue was a classic one for most seasoned ISA firewall administrators; 502 proxy error (request not supported) when accessing a specific site, but the same site can be reached without issue behind any other firewall or router. Clearly the ISA firewall, with its deep application layer inspection capabilities, is objecting to something in the communication stream and denying our request. Now, there are plenty of other documented examples of this type of scenario, but what I found particularly entertaining about this specific one (and hence compelled to write about it here) was the response I see coming from the remote web server…
HTTP/2.0? This was not a specification I was aware of, but as a sanity check I posed this question to some folks that know a lot more about this stuff than I do. Thankfully, Jim Harrison did confirm for me that HTTP/2.0 is not a valid specification. Thanks Jim!
Again, this is a fairly common scenario when you deal with the ISA firewall. Because the ISA firewall is capable of understanding communication at the application layer (layer 7), it is designed for security reasons to disallow ANY non-RFC compliant communication. That includes any fictitious HTTP specifications that vendors decide to dream up as well. And once again, this is another shining example of the power and security of the ISA firewall. With these advanced features, the ISA firewall does far more to protect your network communication than any firewall on the market today. In this instance, had this been a malicious site, any other firewall (certainly my ASA!) would blindly allow the communication.
Connect
Richard Hicks' Forefront TMG Blog 