Those aren't captures - they're pictures. Where are the captures themselves? ________________________________ From: David Farinic [mailto:davidfa@xxxxxxx] Sent: Saturday, March 04, 2006 3:40 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. 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 ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: jim@xxxxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist Report abuse to listadmin@xxxxxxxxxxxxx All mail to and from this domain is GFI-scanned. 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