The very first article I wrote for ISAserver.org is Understanding the Firewall Client Control Channel. That article explains how the Firewall client talks to the ISA Server 2000 through the Control channel by using the Remote Winsock Protocol (RWSP). It shows how authentication credentials, name resolution queries and the Data channel negotiations are sent along the Control channel. Keep in mind that no real data is exchanged on this channel.
The most significant improvement the ISA Server 2004 and later Firewall client has over the previous ISA Server 2000 version is that the Control channel is now encrypted by default. This means that user credentials, who are sent transparently with each request on the Control channel, will not be intercepted by someone who may be “sniffing” the network. The drawback is of course we can no longer monitor the Control channel for diagnostic purposes. Apart from the document Internal Client Concepts in ISA Server 2006 there is no much information found on how exactly the newer Firewall client version works. So, I assume that what I found out with my empirical study of the ISA Server 2000 Firewall client is still largely valid.
On January 18, 2007 a short article was published on the ISA Server Product Team Blog which confirms one of the findings in my article. A KeepAlive packet is sent by the Firewall client every 10 minutes. This means that if a device between the client and the ISA Server has an idle connection timeout configured for less than 10 minutes, then this device will force the closing of the Control channel, with the result that the ISA Server and the Firewall client will drop the Data connection shortly thereafter.
For more information, check out the article TCP connection established using Firewall client may close unexpectedly.