We can’t stress it enough, understanding how the different ISA clients work and how they interact with the ISA server is a key requirement to get the most out of the ISA server. A lot of good information can be found in the ISA help file and Jim Harrison’s excellent articles over at http://www.isaserver.org/Jim_Harrison/. In my article How to pass IPSec traffic through ISA Server I explained on which layer in the TCP/IP protocol stack the different ISA client types work. Because that information can be very helpful, it is well worth a reprint as a separate blog. The following figure shows you a logical view of the TCP/IP protocol stack:

Note: keep in mind that a single host can be configured as a SecureNAT, Firewall and Web Proxy client without any adverse interaction between the client configuration settings.   

Web Proxy client

Unlike the Firewall client, the Web Proxy client is not a piece of software you have to install. It refers to client Web applications that are configured to use the ISA server as Web Proxy server. In most cases it will be a CERN-compatible Web browser. When a Web application is configured to use the Web Proxy service on ISA server, all HTTP/HTTPS requests for destinations not set for direct access are sent to the Web Proxy component on ISA server. That means that those requests are redirected by the Web application itself to the outbound Web Proxy listener on ISA server. In other words, the Web application will ask the transport layer to create a connection to the Internal IP address of the ISA server (a LAT destination) and TCP port 8080, assuming the default configuration of the outbound Web Proxy listener. Because the redirection is done by the Web application itself, we can say that the Web Proxy client is working at the application layer.  

Firewall client

The Firewall client is a very interesting piece of software and it works hand in hand with the Firewall service on the ISA server. In platforms that support Winsock 2.0, the client is implemented as a layered service provider (LSP). On other platforms, the client setup application renames the original Winsock DLL (wsock32.dll) and installs its own implementation of wsock32.dll. The Firewall client communicates with the Firewall service by using a dedicated connection called the Firewall client control channel. The control channel connection is established the first time it is needed. When a client application calls a Winsock function, the client DLL intercepts the call and decides, based on the specified request and the firewall service configuration files, whether the call is local or remote. Local calls are passed to the original Winsock implementation. Remote calls are redirected to the firewall service. In general, all TCP/UDP requests for non-LAT destinations are redirected by the Firewall client software to the Firewall service on ISA server. This is done by rewriting the original Winsock call and replacing some parameters, such as the destination IP address and destination port number, with those negotiated along the Firewall client control channel. Take note that the new destination IP address will be the Internal IP address of the ISA server. Because the redirection is done by the Firewall client software at the Winsock level, the Firewall client is definitely working at the transport layer.

SecureNAT client

Any computer that understands TCP/IP networking and has a default gateway capable of routing Internet bound traffic through the internal interface of the ISA server, is called a SecureNAT client. In a simple non-routed internal network, the default gateway on the clients should be configured with the IP address of the ISA internal interface. If you run a more complex routed internal network, check out Jim Harrison’s article Designing An ISA Server Solution on a Complex Network. Unlike the Web Proxy and Firewall client, no redirection or special processing whatsoever is done at the client site. That means that SecureNAT requests follows the normal packet processing of the TCP/IP stack and that all processing must be done at the firewall service on ISA server. In other words, the destination IP address will be the IP address of the requested destination and the protocol and port number (if applicable) will be the requested ones. Because it depends on the gateway configuration and network routing infrastructure, the SecureNAT client belongs to the network layer.  

Conclusion

With the above knowledge, you should be able to determine how a client host will act for a particular request, even if the host is configured as all three ISA client types.

HTH,
Stefaan

In my article How the FTP protocol Challenges Firewall Security I explain thoroughly how the FTP protocol works and how ISA server supports the FTP protocol. Although that article was written with ISA 2000 in mind, most of the stuff is still valid for ISA 2004, especially the behavior of the different ISA client types. It is crucial that you make yourself familiar with the three different ISA client types and how they interact with the ISA server. For more info about them, check out Jim Harrison’s excellent articles over at http://www.isaserver.org/Jim_Harrison/ and my blog A different look at the ISA Clients.

For SecureNAT and Firewall clients, ISA server supports fully the FTP protocol including active and passive FTP mode. Keep in mind that the FTP mode active or passive is determined by the FTP client itself. For Web Proxy clients, that means FTP over HTTP, ISA is CERN Proxy compatible what means that only FTP download is supported and that active or passive FTP mode is determined by a global configuration setting on the ISA server itself. By default the Web Proxy component on ISA will use active mode FTP. You can alter this behaviour by editing the registry on the ISA server to allow FTP requests made through the Web Proxy component to use passive mode. Check out the KB article HOW TO: Enable Passive CERN FTP Connections Through Internet Security and Acceleration Server 2000 for more info. Although it is not listed in the KB article, I can assure you that the NonPassiveFTPTransfer registry key is also valid on ISA 2004.

I strongly suggest that you test first your full FTP access with the standard Microsoft FTP command line client. If you can login and do a dir command, you have tested the FTP control and data connection. Take note that the Microsoft FTP command line client does not support passive mode. If you need to test passive mode too, use the free FTP command line client MoveIt Freely from Standard Networks. It support Secure FTP too. Once it is working with one of those clients, you can start to play with IE as FTP client.

The most important IE setting regarding the FTP protocol is the setting Enable folder view for FTP sites (Internet Options -> tab Advanced):

• If the IE setting Enable folder view for FTP sites is not checked and you have a rule allowing the FTP protocol, then you will be able to connect to the FTP server with the URL syntax ftp://username:password@FQDN but you will only be able to download files, not upload files. In other words, with this configuration setting IE is acting as a Web Proxy client.
  
• If the IE setting Enable folder view for FTP sites is checked and you have a rule allowing the FTP protocol, then the client must also be configured as a Firewall or a SecureNAT client, depending if you require authentication on the FTP rule or not. In both cases you will be able to connect to the FTP server with the URL syntax ftp://username:password@FQDN and you will be able to download and upload files, assuming the Read Only flag on the FTP rule is cleared. If the Firewall client is installed and enabled, this request is intercepted and handled by the Firewall Client. However, if the Firewall client is disabled or not installed, the request is sent as from a SecureNAT client. Which FTP mode active or passive IE will use is determined by the setting Use Passive FTP (for firewall and DSL modem compatibility).

HTH,
Stefaan

The ISA Corner section of my blog contains all the essential information any ISA administrator needs in order to keep ISA Server at peak performance.

Get the buzz on new Microsoft ISA KB articles, learn how to properly publish different services without exposing the firewall to vulnerabilities; deploy and manage ISA Server; make the most of ISA’s caching; and keep the company network protected against hackers and malware threats.