Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

PIX Connection Timeout

My PIX 515 connection timeout is set to default 1 hour. I have a connection between my inside host and an outside host. This connection will last forever. However, this traffic volume is very low. The connection will idle for more than 10 hours. At the moment, the connection keeps dropping out. The fixed is to restart the connection on the servers.

My question is after the pix connection timeout, the traffic between the servers will be blocked because the connections for the servers on the connection table of the PIX is removed.

Am I right?

  • Other Security Subjects
5 REPLIES

Re: PIX Connection Timeout

Hi .. the connection will be closed only if the connection has been idle for one hour ( in your case). The connection will still opened as long as there is traffic passing throught. If you see the connection droping even thought you knkow it should not then you might be having physical issue here. Check the statuc of the interfaces on the PIX and also check the ports where the servers are connected .. you must have a local switch make sure you are not having errors on it or duplex mismatches.

I hope it helps ... please rate it if it does !!!

New Member

Re: PIX Connection Timeout

I checked both servers, the connections were established. However, the "show conn" on the PIX showed no connection for the servers. The communications between them were broken.

Is the related to the setting of the connection timeout? Why restarted the connections on the servers restored the communications?

New Member

Re: PIX Connection Timeout

add this command

timeout xlate 01:00:00

and check

Bronze

Re: PIX Connection Timeout

You are correct

If you open a connection and no traffic passes over it for whatever the pix/asa/fwsm timeout value is, then the pix will close the connection. Any new traffic from one host to the other would be dropped unless it was the establishment of a new connection.

You need to do 1 of 3 things:

1) Somehow configure your connection to send traffic more frequently, keeping it alive.

2) Configure your connection to close and restart periodically, under the timeout limit in the pix.

3) Configure the pix with a timeout value that is greather than the time between when those hosts are sending traffic to each other.

You have to be careful of #3 - If you increase that value too much you run the risk of filling up your connection table, depending on how much throughput you have on your firewall.

Don't forget to configure your xlate timeout to match your connection timeout.

--Jason

Please rate this message if it helps!

New Member

Re: PIX Connection Timeout

I agree with the Nov 1, 2006 5:39am PST post.

We have seen similar behavior here. Using Wireshark, windump or tcpdump we found that one particular application we use would initiate two TCP connections.

Connection 1 would attach to a license manager and would send traffic every 2-3 minutes.

Connection 2 would attach to a database and only send TCP traffic when the user (via the application UI) would request data.

When the user went to lunch, Connection 2 would be idle for over an hour. During that time, a firewall or IOS router with firewall feature set would tear down the connection.

Upon returning from lunch, the user would request data from the application and receive an application error.

On the network we would see a TCP PSH from the client to the server (not a SYN,SYN/ACK,ACK) followed immediately by a TCP RST from the server to the client.

We have not isolated who was sending the TCP RST (firewall or router). We do know the RST did not come from the server, so has to come from a device between the client and server.

My theory is that the 'after lunch PSH' was viewed as malicious because it did not associate with a known connection (it was torn down per an idle timeout) and this device sent the RST to close the client connection.

Hope this helps.

Another Jason

319
Views
0
Helpful
5
Replies