TCP Connection timeout

[hinesd]

We have a vendor network connected to a DMZ interface on a PIX 515.

THe PIX interface (DMZ2) is addressed on the same subnet as the ethernet interface of the vendor network.

One of teh applications in use, utilizes a "persitent" TCP connection to a pecific port on the vendor (server) side.

We found that after approx 1 hour the connection between client and server would drop. Although the application appeared to be up, no data would pass.

Upon troubleshooting, we noticed a TCP RST from the vendor server. This was captured on an interior Checkpoint Firewall. The RST packet appeared to be coming from the IP address of the server. Further troubleshooting revealed that the packet was originating from the PIX firewall.

Is this expected behavior? after increasing the TCP timout setting, the problem went away.

[msitzman]

It seems like the PIX is resetting the connection based on the default connection timeoute setting. By default, and idle TCP connections will be reset after one hour. You can adjust this timeout setting witht he 'timeout conn' command. You can verify that this is the issue by reviewing the syslog messages at level 6. If you see the connection teardown message stating connection timeout, then you have the culprit.

Marcus

[hinesd]

Marcus,

thanks for the reply. I will run the syslog,but is this expected behavior, for the PIX to offer the RST on behalf of the far end host?

[msitzman]

I would not expect the PIX to do anything but simply close it's conn. The PIX will start resetting conns if the host hits limits in the number of embryonic or established connections.

The syslog messages will indicate this as well...

Marcus

[shannong]

It is normal behavior for the Pix to timeout and close inactive sessions. If the pix does not move any data for the connection, it will be considered idle and timeout according to the default entries shown by [show timeout].

If the pix did not time out inactive sessions, the connection table would continue to grow until the pix exhausted all its memory. This normal behavior for all firewalls to prevent this problem.

What type of OS are the client and server? If it's *nix, you can configure keepalives to prevent this. If it's Windows, you probably screwed.

Do you expect your application to be quiet for periods longer than 30 minutes? That is the default timer for connected sessions. You can increase it, but be careful about making too long. This will be based on the firewall model, available RAM, and the number of sessions it must normally deal with.

[timeoute conn 1:00:00] would increase it to one hour.

-Shannon