>>> On 8/18/2008 at 2:27 PM, Dan Lynch <[EMAIL PROTECTED]> wrote: > 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?
You mean "shouldn't" be reused? It is almost reasonable. If the connection is up, there will be no RST. If there is no connection, then you should get a RST... unless you were to do something really strange and say, have a firewall or something in between the hosts. > How long does Checkpoint (R65 on Nokia) hold a torn-down connection? As someone else eluded to, the TCP standards talk about a 2*MSL timeout. There is a setting called the "TCP End Timeout" in the Global Properties> Stateful Inspection window. I don't know if this is actually what the firewall uses for a Smart Conenction Reuse timer. > 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? The 2*MSL is in the standard and there for a reason. At the end of a TCP connection, like the three-way handshake, there is a two-way finish, i.e. each side closes the connection independently. The side that closed first has to wait for the other side (note that TCP is peer-to-peer once the connection is up, so "client" and "server" are not important here, either one may close first). Eventually, the other side is done too, so it sends a FIN. The local side will ACK the FIN. And here is where the 2*MSL TIME_WAIT comes in. The remote side does not acknowledge that ACK in any way. But that ACK may have gotten lost somewhere on the network and never arrived. If that is the case, the remote should resend the FIN, and the local respond again with an ACK. So, in order to be ready to deal with a lost outgoing ACK and the resent FIN, the local end has to remember the TCP connection. It can't just close it out and forget about it. Thus, the TIME_WAIT state. And obviously for this to work, any stateful TCP packet filter between the hosts has to also keep track of the connection even while it is in TIME_WAIT. > This looks like a broken implementation of a well-intended feature. > Thoughts? It's an interesting, possibly useful feature. What is severely lacking is documentation of the feature and the knobs to control it. See the "Smart Connection Reuse" thread from July of 2007 when I was lucky enough to wrestle with the same problems you are having. But to summarize, # fw ctl set int fw_reuse_established_conn <port> Seems to disable the feature for TCP <port>. Lord help you if you wanted to disable it for more than one port? B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED] 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] =================================================
