RE: TCP/IP HTTP fault tolerant connection ending via ISA server

  • From: "David Farinic" <davidfa@xxxxxxx>
  • To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
  • Date: Sun, 5 Mar 2006 00:39:40 +0100

>Show us your captures.
 
Here they are:
 
IE without ISA: http://img226.imageshack.us/img226/8006/iedirect6pw.jpg
Shows IE response to 'broken'(forcefully terminated) http tcp/ip connection + 
packet captures. 
Highlighted is packet which caused Internet Explorer to DELETE downloaded data 
and REPORT RESET DOWNLOAD (AR flags==Acknowledge + Reset).
webserver:172.16.130.93  webclient:172.16.130.189
 
 
IE Behind ISA: http://img206.imageshack.us/img206/4269/iewithisa9pv.jpg
Shows fault not tolerant response behind ISA server Proxy (port 8080) to 
'broken'(forcefully terminated)  http tcp/ip connection from web server. 
Highlighted are important packets from webserver:172.16.130.189 to external 
interface of ISA:172.16.130.169 with flags==AR==Acknowledge + Reset  and its 
representative ending by ISA server:192.168.0.1 to proxy client:192.168.0.2 
with flags AF==Acknowledge + Final.
 
 
Iam also incluing same test with FireFox browser which showed same behavior as 
IE:
Direct:http://img389.imageshack.us/img389/7876/firefoxdirect6ph.jpg
 
Behind ISA: http://img333.imageshack.us/img333/6603/firefoxwithisa6gm.jpg 
 
Let me note that I tested/observed same behavior with other win proxies:  
WinGate,Kerio,Squid for windows(2.5).
However I don't see any technically justification for this 'limitation'. 
 
 
Regards David Farinic.
 
 
 
________________________________

From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx] 
Sent: Thursday, March 02, 2006 6:56 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: TCP/IP HTTP fault tolerant connection ending via ISA 
server
 
http://www.ISAserver.org
Show us your captures.
I'll bet ISA sent all it had received from the upstream server before the RST 
appeared.
Also, receiving a RST from the upstream is not a "broken connection", it's a 
"forcefully terminated" one.
The context for each is very different at the application layer.
 
________________________________

From: David Farinic [mailto:davidfa@xxxxxxx]
Sent: Thu 3/2/2006 8:04 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: TCP/IP HTTP fault tolerant connection ending via ISA 
server
http://www.ISAserver.org <http://www.ISAserver.org> 

>Therefore it's not reasonable (or sane) to expect a "TCP mirror effect" at 
>>both ends.

That is true.
Described case did not expect tcp/ip mirroring for http from ISA server.

Proxy server is free to stop data, postpone, translate them etc.

ISA Proxy reports connection errors(timeouts etc..502..) with its own pages 
which are sent as full http responses from ISA server.

Problem happens when passing of data (data pumping) to client already started 
and connection error occurs during download:

ISA Proxy does not inform client about broken connection from server as its not 
passing same tcp/ip ending information which has specific meaning for HTTP 
protocol/applications (tested with netwatch(sniffer) in front and behind ISA 
server by killing webserver process during client's download).

Well it is not a problem if we are aware about it. 
It would be nice if proxy would try to *translate* original webserver 
connection as much as possible especially if its creating problems for clients 
and its expected.

Another small example:

 At office you download/save zip file from internet via ISA server on your 
notebook as you are in hurry, you don't check/extract documents stored in 
downloaded zip files immediately.

On airplane you try to extract crucial documents from downloaded zip file... 
and upss... zip CRC checksum error ...
 uhh how could it happen...
simple:
ISA didn't pass connection error information at the end of download before you 
saved it to disk. IE reported file downloaded ok ... so you felt safe to not 
recheck. IE would report to you immediately that download broke if it wouldn't 
be behind ISA server.
So ISA knew about problem with this download but it didn't pass to you this 
info.. So much for small RST/FIN differences.


Regards David Farinic.

-----Original Message-----
From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx <mailto:Jim@xxxxxxxxxxxx> ]
Sent: Thursday, March 02, 2006 3:49 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: TCP/IP HTTP fault tolerant connection ending via ISA 
server

http://www.ISAserver.org <http://www.ISAserver.org> 

Web proxy traffic is not a "TCP path through ISA" in the same way that 
SecureNET traffic is,  Therefore it's not reasonable (or sane) to expect a "TCP 
mirror effect" at both ends.

If (as you describe) the client continues to send traffic on a half-closed 
connection, then the problem is at the client; not the proxy.

-----Original Message-----
From: Alexandre Gauthier [mailto:gauthiera@xxxxxxxxxxxxxxxxx 
<mailto:gauthiera@xxxxxxxxxxxxxxxxx> ]
Sent: Thursday, March 02, 2006 6:42 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: TCP/IP HTTP fault tolerant connection ending via ISA 
server

http://www.ISAserver.org <http://www.ISAserver.org> 

I'd like to corroborate, I observed this behaviour as well.

-----Message d'origine-----
De : David Farinic [mailto:davidfa@xxxxxxx <mailto:davidfa@xxxxxxx> ]
Envoyé : 2 mars 2006 09:29
À : [ISAserver.org Discussion List]
Objet : [isalist] TCP/IP HTTP fault tolerant connection ending via ISA server

http://www.ISAserver.org <http://www.ISAserver.org> 


[WebServer] http connection-> Reset(RST) [ISA] ->FIN! [Web Client]

Observed consequences:

-When posting to web forums with HTTP POST and reply from webserver is
for     some internet spaghetti reason broken, ISA gets tcp ip http
connection      ending with RST ISA translates it to web client behind
it as FIN ...   which leads to web clients believing they got data
correctly       completely!

        On web forums this results in double posting (as users don't see
their   reply).

-AV updating services might not update their signature databases on
time.

This might cause potential problem with web-services and other
communication utilizing HTTP protocol.

REASON: Web applications reports wrong data retrieval only if TCP/IP
carrying http ends with Reset(RST) packet.

WORKAROUND: adding data integrity checking into data/sub-protocol
utilizing http carrier.

Tested on ISA2k4 and ISA2k:

With Kind Regards David Farinic.

 
This mail was checked for viruses by GFI MailSecurity.
GFI also develops anti-spam software (GFI MailEssentials), a fax server (GFI 
FAXmaker), and network security and management software (GFI LANguard) - 
www.gfi.com


All mail to and from this domain is GFI-scanned.

Other related posts: