We have users who connect via browser to a website that lists details of phone calls made from our jail. The web app allows users to download recordings of phone calls. When selecting multiple recordings to download, the app seems to work fine for a few minutes, then returns a timeout error. Tracker shows the client's HTTP connection, and another connection to tcp port 3001. Nothing unusual is noted in the logs.
I performed packet captures at both my client and at our firewall's internet-facing interface. The browser seems to use at least two TCP sessions: HTTP looks to be used as a control-type connection, while a connection to the server's TCP port 3001 is used to transfer files. That data connection always uses source port 3000 at the client. Outside the firewall though, the source port is changed by our address translation. After the first file is transferred, the data connection is torn down, and a new data connection is attempted using the same source port. At the client that looks like TCP SYN packets from source port 3000 to destination port 3001. Outside the firewall though, those packets no longer have the SYN flag set. Instead the ACK flag is set and an acknowledgement number is inserted. Is this the "Smart Connection Re-use" feature at work? sk24960 reads in part: "When a client tries to reuse a TCP connection that is in an established state in the VPN-1/FireWall-1 connections table (by sending a SYN packet), VPN-1/FireWall-1 allows this packet, but converts it to an ACK packet. Based on the server's response to this ACK packet, VPN-1/FireWall-1 detects the true connection state and adjusts itself accordingly. " In our case, the connection has been properly torn down, but the firewall apparently still considers it as established. New connection SYN packets are converted to ACK packets, which are silently dropped at the far end. The application retries but finally times out. The ACK packet should generate a returning RST unless the server is behind a firewall. A Checkpoint firewall will silently drop an out of state ACK packet by default, no? My questions are: Is it reasonable for Checkpoint to assume that the absence of a RST packet means the connection is still valid and should be re-used? How long does Checkpoint (R65 on Nokia) hold a torn-down connection? Why would the firewall maintain state of a fully closed connection at all, let alone arbitrarily modify packets sent as part of a new connection establishment? This looks like a broken implementation of a well-intended feature. Thoughts? Dan Lynch, CISSP Information Technology Analyst County of Placer Auburn, CA Scanned by Check Point Total Security Gateway. ================================================= To set vacation, Out-Of-Office, or away messages, send an email to [EMAIL PROTECTED] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [EMAIL PROTECTED] =================================================
