In my blog Require 128-bit Encryption for HTTPS Traffic with ISA Server 2006 (Part2) we analysed what the setting Require 128-bit encryption for HTTPS traffic really means and how it works. By default the Web Proxy component on ISA checks for every HTTPS request if the secure channel used to pass that request has a strong Cipher Suite (at least 128-bit encryption) as property. However, it does *not* prevent the setup of a secure channel with a weak Cipher Suite.

In this last part, we extended the second scenario as outlined in part 2 of this blog series by adding an authentication scheme to that scenario, be it on the web listener or on the web publishing rule. First we tested this new scenario with Basic authentication and were very astonished we got an authentication prompt as shown below:  

Only *after* a successful authentication, we saw the expected IE error page: “Error Code: 403 Forbidden. The page requires 128-bit encryption, an enhanced security mechanism. To view the page contents, use a browser that supports this enhanced encryption (12212)”. Straightaway we tested this scenario with Forms Based authentication and got the same result. Hmm… this means that the authentication is done over a secure channel with a weak Cipher Suite!  

We contacted Microsoft PSS and logged a case for this issue. The outcome is that the ISA developers confirmed my observations and that they are a result of a limitation in the current ISA Server 2004/2006 versions. The good news is that this behavior will change in ISA Server 2006 SP1. For the current ISA 2006 version and all ISA 2004 versions up to and including SP3, you should implement the workaround I mentioned in part 2 of this blog series. Also, this issue will be documented in the upcoming KB Article 937293.

In conclusion, we can say that rolling out KB Article 245030 into all ISA installations to disable the weak SSL/TLS Cipher Suites should be part of the standard hardening exercise for any ISA Server. You can apply the following registry file to accomplish that:

REGEDIT4
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers]
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 64/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
“Enabled”=dword:ffffffff

HTH,
Stefaan

Recently I reviewed my article A simple routing table trick and decided to finally check it out in my lab. I must admit that I didn’t test out that scenario at the time of writing that article, mainly because I could rely on a trusted source …   

In my lab http://users.skynet.be/spouseele/VPC-SPLAB.pdf I added the IP address 10.10.10.10/24 to the Local ISA external interface (192.168.1.10/24) and the IP address 10.10.10.30/24 to the Local ROUTER interface (192.168.1.30/24). The device ROUTER, a Windows 2003 SP2 RRAS server, was used to fulfil the role of the DSL Bridge shown in the original article.

The resulting IP configuration on the Local ISA server was:

The resulting routing tabel on the Local ISA server was:

The funny part was now that I did *not* need to define a static route to make sure that the source IP address ‘10.10.10.10′ was used for the traffic destined for ‘10.10.10.30′. It happened automatically as well when testing from the Local ISA server itself as from behind it (Local Internal Network 192.168.22.0/24). Take note that I tested this scenario with ISA 2006 on Windows 2003 SP2. Obviously, I was a little bit surprised and contacted Jim Harrison to check out if he could confirm my findings. Here is his answer:

[quote]
When I was working through that discussion (my own DSL bridge is what prompted the investigation), I noted that the routing table was built using the default gateway, rather than the local-net IPs. That’s what prompted my inclusion of the manual route.
Since then, I noted (as did you) that the manual route shouldn’t be necessary, and in fact, when I built a replacement ISA (moving to 2006), this was not required. I think it may have been because I had so many routes defined in RRAS that this was required, but I can’t say for certain now because it’s gone…
[/quote]

Thus, assuming no route is defined for a “super-net” of the subnet used between the ISA server and the DSL Bridge, it shouldn’t be necessary to configure a persistent static route to make it work. Also, it might be a good idea to minimize the mask of that subnet in order to avoid a possible IP conflict. In the above example, the smallest subnet we could create is 10.10.10.0/30 (mask 255.255.255.252). This gives us only two valid IP’s: 10.10.10.1 & 10.10.10.2. Of course, if such a “micro-net” can be used depends on the IP configuration capabilities of the LAN interface of the DSL Bridge, at least when playing by the book.

HTH,
Stefaan

In my blog Require 128-bit Encryption for HTTPS Traffic with ISA Server 2006 I posted a workaround for enabling Redirect all traffic from HTTP to HTTPS *and* Require 128-bit encryption for HTTPS traffic in a web publishing rule. However, what does that setting Require 128-bit encryption for HTTPS traffic really means and how does it work?

According to the ISA help file, the setting Require 128-bit encryption for HTTPS traffic means: Click to specify that HTTPS requests that do not use 128-bit encryption will be blocked. Hmm… does that mean that the ISA Server will refuse HTTPS requests if they are send over a secure channel (SSL/TLS) that uses a weaker encryption algorithm, or that a secure channel (SSL/TLS) will not be setted up in the first place when both parties don’t agree on a strong encryption algorithm?

To find it out, we have to watch the SSL/TLS handshake protocol with a sniffer like NetMon or Wireshark. Particular we are interested in the Client Hello and Server Hello messages used to negotiate the Cipher Suite, that is a list of key-exchange algorithms and Cipher Specs supported.  Of course, this means that you need a basic understanding on how the SSL/TLS handshake protocol works. Some good resources to learn more about the SSL/TLS handshake protocol are:

• Secure Socket Layer
• Welcome to the SSL Tutorial

Now that we know what to look for and assuming that we have a properly configured ISA Server with a sniffer enabled on the external interface, we also need a method to define which Cipher Suites will be offered by the client and/or will be accepted by the server during the SSL/TLS handshake. In that way we can determine how ISA Server will treat a none compliant client (or a bad guy). The key to the whole discussion here is the Microsoft Knowledge Base Article 245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll. Take note that the SChannel is the heart of the Windows cryptographic mechanisms. Therefore ISA server rightly defers to Windows for all encryption. In other words, ISA server should just been seen as a consumer of the Windows SChannel stuff, not as the owner of it.

In the first scenario we use a standard Windows XP SP2 client and a standard ISA 2006 SE server (on Windows 2003 SP2) with the setting Require 128-bit encryption for HTTPS traffic enabled. Here is an excerpt of the SSL/TLS handshake:

If we go into the details of the Client Hello message (frame #4), we get the following information:

As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes 11 Cipher Suites to the server from which the server should choose one, normally one of the strongest. The Cipher Suite chosen by the server is then reported back to the client in the Server Hello message (frame #5-6) as shown in the figure below:

As you can see a strong cipher is chosen by the server. This completes the analyses of the SSL/TLS handshake in the context of this blog.

In the ISA logging you should find the following sequence of events:

In the second scenario we configure the client so that only weak ciphers are proposed to the server. To accomplish that we use KB245030 to disable the SChannel Ciphers RC2 128/128, RC4 128/128 and Triple DES 168/168 located under the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key in the registry. When we try now to access the exact same published web site as in the first scenario, IE gives the following error page:

 

This sounds good because we can’t access anymore that published web site as expected. However, due to the fact we get a specific error page ”Error Code: 403 Forbidden”, we can assume that ISA reported the error code back to the browser. As a result the SSL/TLS session must have completed successful, otherwise no communication path was available between the browser and the ISA server to send that message. So, let’s verify that with the help of a network trace. Here is an excerpt of the SSL/TLS handshake:

If we go into the details of the Client Hello message (frame #6), we get the following information:

As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes now only 7 Cipher Suites to the server from which the server should choose one, normally one of the strongest. The Cipher Suite chosen by the server is then reported back to the client in the Server Hello message (frame #7-8) as shown in the figure below:

As you can see the server could not select a strong cipher because no one was offered. Thus a weak one was indeed chosen by the server to be able to report back the error page ”Error Code: 403 Forbidden” to the client. Take note that no other data is allowed by the ISA server because the negotiated cipher didn’t fulfil the Require 128-bit encryption for HTTPS requirement.

In the ISA logging you should find the following sequence of events:

In the third scenario we additional configure the server so that only strong ciphers are accepted. To accomplish that we use again KB245030 to make sure that only the SChannel Ciphers RC2 128/128, RC4 128/128 and Triple DES 168/168 located under the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key in the registry are enabled. All other SChannel Ciphers should be disabled. When we try now to access the exact same published web site as in the first scenario, IE gives the following error page:

Again, this sounds good because we can’t access anymore that published web site as expected. However, due to the fact we get a generic error page, we can assume that the server actively refused the SSL/TLS session. As a result the Web Proxy component on ISA was never aware of that connection attempt. So, let’s verify that with the help of a network trace. Here is an excerpt of the SSL/TLS handshake:

If we go into the details of the Client Hello message (frame #8), we get the following information:

As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes again only 7 Cipher Suites to the server from which the server should choose one, normally one of the strongest. However, instead of responding with a Server Hello message, the server closes the TCP connection (frame #9-13). The obvious reason for this is that the client was configured to only propose weak ciphers and that the server was tuned to only accept strong ciphers. Thus no common Cipher Suite could be negotiated and therefore the SSL/TLS negotiation was aborted. 

In the ISA logging you should find the following sequence of events:

In conclusion we can say that if the setting Require 128-bit encryption for HTTPS traffic is enabled then the Web Proxy component on ISA checks for every HTTPS request if the secure channel used to pass that request has a strong Cipher Suite (at least 128-bit encryption) as property. However, it does *not* prevent the setup of a secure channel with a weak Cipher Suite. If you want that level of control then the registry changes to limit the SSL/TLS Cipher Suites (KB245030) are the right answer. Take note that limiting the SSL/TLS Cipher Suites is a machine global configuration. Thus you can’t control that on the rule level.

We can debate about which approach is the best. Personally, I would like to see that a new Global HTTP Policy Setting was added to the ISA Server MMC (Configuration -> General) which gives us the choice to only enable the strong SSL/TLS Cipher Suites. Of course, when this new Global HTTP Policy Setting would be enabled then the Require 128-bit encryption for HTTPS traffic setting on the rule level should be automatically deactivated (greyed out).

HTH,
Stefaan

—– Begin Original Message —–
From: isapros-bounce@freelists.org On Behalf Of Jim Harrison
Sent: zaterdag 17 maart 2007 22:45
To: isapros@freelists.org
Subject: [isapros] WS03 SP2 and ISA 2004/6 Ent Edition

For those of you who are considering deployment of Windows 2003 SP2 on your ISA 2004 or 2006 CSS server, you better be reading the SP2 relnotes (you better be doing it anyway, yanumpty).

The short story is this. If you install WS03 SP2 over ADAM RTM (as is delivered in ISA 2004 & 2006 for WS03 RTM & SP1), you will break ADAM. This does not occur if your ADAM instance was installed as part of WS03 R2. Otherwise, you *MUST* get and install ADAM SP1 before installing WS03 SP2.

You can get ADAM SP1 (already part of WS03 R2) here:
http://www.microsoft.com/downloads/details.aspx?Fa...B5C8E4

You can get Windows 2003 SP2 here:
http://www.microsoft.com/technet/windowsserver/sp2.mspx

You can check out the readme here:
http://go.microsoft.com/fwlink/?LinkId=75002

You can get the WS03 SP2 Relnotes here:
http://go.microsoft.com/fwlink/?LinkId=75107  

Ain’t life grand?

Jim
—– End Original Message —–

HTH,
Stefaan

You create a secure web publishing rule (SSL Bridging). In the tab Traffic on the Web publishing rule you will see that:

• the checkbox Notify HTTP users to use HTTPS instead is not available (greyed out).
• the checkbox Require 128-bit encryption for HTTPS traffic is available.

Next, you want to change the rule so that HTTP traffic will be redirected as HTTPS traffic. Therefore you go to the Web Listener, tab Connections and make the following changes:

• check the box Enable HTTP connections on port (default port is 80).
• select the radio button Redirect all traffic from HTTP to HTTPS.

You apply the changes and verify that everything is working as expected.

Finally, you want to enforce 128-bit Encryption for HTTPS traffic. So, you go the Web publishing rule, tab Traffic and see that:

• the checkbox Notify HTTP users to use HTTPS instead is not available (greyed out).
• the checkbox Require 128-bit encryption for HTTPS traffic is also not available (greyed out).

Why?!?! Hmm… how can we redirect HTTP to HTTPS *and* require 128-bit encryption in one step?

After some experimenting I found out that you can get it to work if you perform the following steps in sequence:

• go to the Web Listener, tab Connections and make sure you select the radio button Do not redirect traffic from HTTP to HTTPS.
• next go to the Web publishing rule, tab Traffic and you will see that the check box Notify HTTP users to use HTTPS instead becomes available. Check that box.
• by doing that the check box Require 128-bit encryption for HTTPS traffic becomes also available. So, check that box too.
• finally, go back to the Web Listener, tab Connections and now select the radio button Redirect all traffic from HTTP to HTTPS.

Now, apply the changes and verify that on the Web publishing rule, tab Traffic you see the following:

• the checkbox Notify HTTP users to use HTTPS instead is checked but not available (greyed out).
• the checkbox Require 128-bit encryption for HTTPS traffic is checked and available.

Why this strange dependencies in the GUI? This really sounds like a bug because I can’t figure out the logic behind this!

So, I contacted Microsoft PSS and logged a case for this GUI problem. They confirmed my findings and are investigating how to fix that GUI problem. In the mean time, you can use the workaround I posted above.

HTH,
Stefaan

In my blog Playing with Radius Authentication and ISA Server 2006 I created the necessary environment to test out in a generic way, that means independent of any real hardware token system, the use of a two-factor authentication system with ISA Server 2006. That test environment is based on a non-domain joined Radius OTP service (IAS) as authentication provider for the users and on the capability of the ISA Server 2006 to use Kerberos constrained delegation for authentication on behalf of the users to the published service. 

For normal Web publishing such as Outlook Web Access this works great. As shown in the diagram below, the basic configurations steps are: (1) on the Web Listener we use Forms Based Authentication (FBA) and select Radius OTP as Authentication provider and (2) on the Web Publishing rule we use Kerberos constraint delegation to the published Web Server. 

Keep in mind that for Radius OTP the authentication is only done once per session. ISA Server issues a cookie to the client that allows continued communication without re-authenticating.

In my quest for strong user authentication I want to find out if the above concept could also be used for RPC over HTTP services such as Outlook Anywhere (Outlook 2003/2007) and the upcoming TS Gateway in Longhorn. So, let’s draw a little diagram to outline the different components:

On the client side we have two main components. First of all the client programme itself which can be the Outlook 2003/2007 client (OLK) or the Remote Desktop Connection client (RDC) version 6. Secondly we have the RPC over HTTP Proxy client (RPC Proxy Cln) integrated in the OS from Windows XP SP2 onwards.

On the server side we have also two main components. First of all the server programme itself which can be the Exchange 2003/2007 Front End server (Exch FE) or any Terminal Server service (TS Srv) as well as any Remote Desktop service (e.g. Windows XP). Secondly we have the RPC over HTTP Proxy server (RPC Proxy Srv) as an extra Windows Networking Service that integrates into IIS on Windows 2003 and Longhorn. Take note that on Windows 2003 the RPC over HTTP Proxy server only supports the Exchange 2003/2007 server programme. On Longhorn the RPC over HTTP Proxy server together with some additional components can be used as TS Gateway too.

On the ISA Server we extended the Outlook Web Access publishing rule with the RPC over HTTP functionality, this means adding the correct RPC path. Thus, as shown in the diagram above, the basic configurations steps are still: (1) on the Web Listener we use Forms Based Authentication (FBA) and select Radius OTP as Authentication provider and (2) on the Web Publishing rule we use Kerberos constraint delegation to the published Web Server. Take note that ISA Server will evaluate the user-agent field in the HTTP header. For RPC over HTTP the value of the user-agent field is set to ”MSRPC” by the RPC over HTTP Proxy client. Because ISA Server knows this user-agent doesn’t support Forms Based Authentication, Basic authentication will be used as a fall-back mechanism instead.

The first thing we have to find out is if the RPC over HTTP Proxy client itself is capable of supporting a different set of credentials to authenticate against the ISA Server (1) and the published server (3). In the Windows Server 2003 Resource Kit Tool you can find a little tool called the RPC Ping utility. It can be used to troubleshoot connectivity issues with RPC over HTTP and it’s usage is explained in the KB article How to use the RPC Ping utility to troubleshoot connectivity issues with the Exchange over the Internet feature in Outlook 2007 and in Outlook 2003. In my lab environment the RPC Ping utility was used as follows:

• Create in Active Directory two users ‘SP’ and ‘Test’ with different passwords. The user ‘SP’ has an Exchange mailbox.
  
• Create in the non-domain joined IAS also the user ‘Test’ but with a different password from the password used within Active Directory.
  
• From an external host use the rpcping command to test the connectivity to the Exchange Information Store service (6001):

  C:>rpcping -t ncacn_http -s adc.intranet.splab.net -o RpcProxy=mail.intranet.splab.net -P "test,SPLAB,*" -I "sp,SPLAB,*" -u 10 -a connect -H 1 -u 10 -v 3 -F 3 -e 6001

  which give the following successful result:

  RPCPing v2.12. Copyright (C) Microsoft Corporation, 2002
  OS Version is: 5.1, Service Pack 2
  Enter password for server:
  Enter password for RPC/HTTP proxy:
  Completed 1 calls in 501 ms
  1 T/S or 501.000 ms/T

  Take note we used the IAS user ’test’ to authenticate against the ISA Server (1) and the AD user ’sp’ to authenticate against the published server (3).

• In the IIS logging of the RPC over HTTP Proxy server we have the following entry:

  2006-11-28 08:28:54 192.168.22.3 RPC_OUT_DATA /rpc/rpcproxy.dll adc.intranet.splab.net:6001 443 SPLABtest 192.168.22.1 MSRPC 200 0 0 

  This proves that the ISA Server can authenticate successful on behalf of the user ‘test’ with the help of the Kerberos constraint delegation mechanism (2).

The above test scenario demonstrates clearly that the RPC over HTTP Proxy client itself is capable of supporting a different set of credentials to authenticate against the ISA Server (1) and the published server (3). However, does that also mean it can support the use of a two-factor authentication system with ISA Server 2006?

The pitfall here is the authentication method used to authenticate against the ISA Server (1). As far as I know the RPC ping utility exposes all the methods the RPC over HTTP Proxy client is capable of. That means that only Basic and NTML authentication is supported (rpcping -H argument). Also, on the ISA Server you have to select Forms Based Authentication on the Web Listener in order to be able to check either Radius OTP or RSA SecureID as Authentication provider. However, with the RPC over HTTP Proxy client (user-agent = MSRPC) the ISA Server will fall-back to Basic authentication, even when FBA is configured. 

The problem is now that if you change the authentication method on the Web Listener to Basic authentication instead of FBA than you can’t select neither Radius OTP nor RSA SecureID as Authentication provider. In other words, FBA itself seems to be the only valid method to acquire the Radius OTP credentials. This isn’t that illogical because the authentication should only be done once per session and ISA Server must issue a cookie to the client that allows continued communication without re-authenticating. We can’t ignore that those requirements doesn’t fit well the characteristics of the Basic authentication method.

If we look now at the client side than we see that the Outlook 2003/2007 client cannot use two different set of credentials to authenticate against the RPC Proxy server and the Exchange Server. In other words, it will send to the Exchange Server the same credentials used to authenticate against the RPC Proxy server. This is by design and there is no work around possible. Moroever, although the Remote Desktop Connection V6 client prompts for two sets of credentials, it supports only NTLM and Smart Card to authenticate against the RPC Proxy server. As a result it looks very much we are stuck with the client capabilities too.

With confirmation from Microsoft PSS and Jim Harrison, I can assure you that what I want to achieve is *not* possible with the current RPC over HTTP code in the client. In other words, it’s unreasonable for us to expect any non-browser such as an RPC over HTTP client to have any FBA capabilities. Moreover, it can not been solved by “fixing a bug”, but rather it would require Design Change Requests (DCRs) within multiple products. Therefore, it’s very unlikely it will happen unless there is a huge customer demand.

Thus, my conclusion is that if single-factor authentication (read passwords) is good enough than the RPC over HTTP stuff is really useful. Otherwise, a VPN is the only current Microsoft answer for “more” authentication with the ISA Server 2006. Maybe we should take a look at the new Microsoft product Intelligent Application Gateway (IAG) 2007 to find out if it can solve this kind of problems. The IAG 2007 product is announced as the comprehensive, secure remote access gateway that provides secure socket layer (SSL)-based application access and protection with endpoint security management.

HTH,
Stefaan

In my blog Redirecting OWA Users to the Correct Directories and Protocols with ISA Server 2006 I reported a problem with my OWA publishing rule with ISA Server 2006. Removing the special path mapping I used with ISA Server 2004 to translate the root path “/” to the special Exchange path “/Exchange\” solved the problem. To resolve the redirection problem, I implemented the redirection in the ‘default.htm’ file in the root directory of the OWA site as described in my blog.

On January 24, 2007 Microsoft published a new KB article You cannot apply an OWA Web publishing rule that redirects users who connect to the root of the OWA Web site to an internal folder by using ISA Server 2006 that seems to apply to the OWA path mapping problem I reported. To resolve this problem, you need to install the update that is described in the KB article Update is available that supports publishing Microsoft Exchange Server 2007 behind Internet Security and Acceleration (ISA) Server 2006.  I downloaded this update and installed it in my ISA lab. Next, I implemented once again the special path mapping to translate the root path “/” to the special Exchange path “/Exchange\” and removed the redirection in the ‘default.htm’ file in the root directory of the OWA site. Finally, I rebooted the ISA server to be sure that there are no startup problems and tested out the redirection by just entering the FQDN of the OWA site in IE. The redirection of the protocol and the path was working flawless.  

HTH,
Stefaan

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.

HTH,
Stefaan