TCP Timeouts ... Again

[jickfoo]

I have a bunch of connection, 12 to be exact. From a webserver to a Oracle DB Server. They timeout every 2 hours. 

They pass through a Cisco ASA and a PA 4020. I've created and override rule with a custom app with no timeout. (see attached)

I'm in the position where I need to prove this is not the Palo Alto killing the connection. I'm sure it's not closing naturally. Something is killing the connection.

How can I prove this on the PA? I know when the connections are going to die. I'm going to do a packet capture with the debug flow commands. Any hints on what to look for ? Will I see TCP RSTs or Fins sourced from the PA ?

Thanks,

Justin

[jickfoo]

so I did the debug trace.. Not as easy as a tcpdump but whatever. In the Drop trace I see PA dropping keep alives. See attached. Any ideas ? Is PA dropping keep alives which is why I am getting idle sessions terminating ? If so, where can I change this ?

[mderksen]

Hi,

Two remarks:

- From the first picture you send it seems that you did not set the timers. This means that the default timers will apply. If you want to set your own timers please configure them in the application. If you want the session to not time out set the timeout to zero (0).

- If you want to prove the Palo Alto Networks is not the problem then if the session is killed see if the session is still in the session table of the Palo Alto Networks. This might prove easily (before taking any captures) that the session is still active.

Marcel

[jhickey]

Thanks, I think we had this conversation before. Someone told me that the greyed out timers is an indication that they are off. If I set them to 0 it goes back to what you see there. I can set them to 2 weeks and see if it bypasses the 2 hour timeout.

How do I look at the session tables ?

I did run the captures already. Any thoughts as to why there was data in the drop capture ?

Thanks,

[mderksen]

You can look at the session table with the command from the CLI or (if you have) via the option in the monitor and use the session browser.

From the CLI use the command 'show session all' and use the filter command to make it useful.

Marcel

[jhickey]

k thanks.. I have a case open and I'll report back what happens. I thought we had success last night as I set the settings from they greyed out zero to the max 604800 and there was no timeout .. until 6 hours later. (not the usual 2 hours) BUT to complicate things there was also a bit of a network outage last night around the same time.

I set the timers back to the greyed out zero and will find out in about 40 minutes if the sessions crash again.

To me there should be an easier way to see if a session was closed due to the firewall thinking it is idle. It should be in the logs. (Session Close: Reason: FW TCP Timeout)

[jhickey]

The sessions did get taken down again. I'm fairly certain the Palo Alto Firewall took it down.

I set the timeout to 604799 and restarted the services. It's been 6 hours now and the connection is solid.

So, in conclusion, 0 = 2 hours.

I still think there should be a way to prevent the PA from ever tearing connections down due to 'idle timers'.

I made the request.

Thanks,

Justin

[opiedrah]

We had a similar problems recently, after a call with Support it was determined that we modified some tcp timeout timers. The below commands resovled our issue.

PAN>configure
PAN#set deviceconfig setting tcp drop-out-of-wnd no
PAN#set deviceconfig setting tcp bypass-exceed-oo-queue yes