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