Persistent TCP connection keeps dropping

[m-raft]

I have a web server on my DMZ that needs a persistent TCP connection to an internal host. My problem is this connection keeps dropping after an hour or 2. I have my conn timeout set to 8 hours and my xlate timeout set to 3 hours. Is there a way on the pix to set up a persistent connection so idle timeouts don't tear down the connection? Also, with my timeouts set as stated why would the connection drop after 1 or 2 hours? I would understand if the connection dropped after 3 hours of idle time based on the xlate timeout, but that is not what is occuring.

Any ideas???????

[scoclayton]

Hi,

You can change this the conn timeout to 0:0:0 which will force the PIX to never time out a connection due to an idle timeout. However, this is not a recommeded setting as it will cause the PIX to be unable to remove an conns left idle or unclosed. Depending on how many of these you have, you can consume all resources on the PIX and make it unusable so use at caution.

As for determining why the conns are getting torn down, setup a syslog server (if you do not already have one) and set the syslog level to debugging and see what the PIX is logging when the conn is torn down. It will give you a reason for the teardown. If you need some help deciphering this info, let me know. Good luck.

Scott

[m-raft]

thx, just set the logging to debug and getting ready to reestablish the connection (it timed out again), I will let you know when it drops again and what the syslog entry was. Unfortunately, I was directed to change the timeouts to 240 hours so I'm not sure if the connection will drop anytime soon.

Quick question though, do I need to set the xlate timeouts to match my connection timeout? In other words, if the xlate timeout is hit at 3 hours of idle time won't the connection be dropped anyway or does the connection entry override the xlate entry?

Thanks again,

Mike

[scoclayton]

Cool, let me know what you find. As for your other question - "The connection timer takes precedence over the translation timer, such that the translation timer only works after all connections have timed out."

From http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/tz.htm#1026093

Hope this helps.

Scott

[m-raft]

Okay, got the disconnect with a Reset-I. From reading the documentation I understand that the internal host is sending a TCP packet with the rst flag set. Would that be your diagnosis of this as well? That tells me that the application on the internal box is no longer listening on the port the application is supposed to be listening on and is sending a rst in response to a syn packet. If it was a normal tcp connection termination I should get a fin packet shouldn't I? Or is the reset just PIX terminology for a closed connection?

Thanks again....

Mike

[scoclayton]

Excellent diagnosis. For whatever reason, the inside host (or host on the higher security interface) is sending a RST packet back to the outside host (or host on the lower security interface). The PIX sees this and subsequently removes the connection from the table. Once this occurs, a new 3 way handshake needs to occur between the 2 hosts before the connection can be built again. A "normal" TCP close sequence is a FIN | FIN ACK | ACK which causes the PIX to also tear the connection down. The PIX can accomodate both situations. Might be time to take a look at the application or the host on the inside interface. Perhaps it does not like leaving a connection open indefinetly? Let me know if I can help in any other way.

Scott