Xlate timeout value

[b.withrow]

On our PIX we have an Xlate timeout of 1:00:0 (timeout xlate 1:00:00). We are running into a problem with some of our web servers. For example one web server is on the inside interface and the other server is on DMZ50. A constant connection must be maintained between these two devices (for sync). If the connection drops, another connection is established. This continues to happen every hour (timeout value of the xlate's) until the DB server complains of too many connections. Is there any way to get specific and tell the pix to have a greater timeout value for this particular conduit? I don't want to create a global timeout (obviously). If that won't work, does anyone have any suggestion as to how we could fix this problem? Thanks in advance!

[wolfrikk]

I am guessing that NAT is being used between the DMZ and the inside since the Xlate timeout is causing the problem. I would create a static mapping from the DMZ to the inside web server.

static (inside,DMZ) netmask 255.255.255.255

[shannong]

We are dealing with two different timeouts here. The "xlate" timeout is for translations, and I doubt this is your issue. The xlate timeout will only have effect if no new connections are created by a host for the time period.

The "conn" timeout is how long a connection should remain open if no traffic is seen between two "connected" hosts. This is more likely the one causing your problems if it's really the firewall causing this. If they are keeping "in sync", do you really expect them not to send ANY traffic for over an hour. If that really is the normal scenario, the firewall may be the "problem".

Unix systems can be configured to use TCP keep alives. This will cause the pix to never see that connection as idle and timeout the session.

If windows, then you're more limited. You could increase the "conn" timeout value to avoid the quiet periods of your web servers assuming their quiet periods aren't something really long such as 6 hours. What are the web servers? What is the application maintaining this connection? Do you really expect these long quiet periods? What do packet captures show about this?