TCP TimeOut caused by the PA?

Showing results for 
Search instead for 
Did you mean: 

TCP TimeOut caused by the PA?

L3 Networker

We have a video app that is streaming through our Palo Alto firewall on port 80. Everyone once in a while the session fails and can only be revived by hitting refresh in the browser. I am dealing with a network manager that's convinced the PAs are Resetting the session.

Before I go through the hassle of creating override policies for port 80 with higher timeouts I'd like to know if there is anything in the logs that would show that the PALOALTO Terminated the connection. The CISCO Firewalls put something in their logs (TCP Timeout). I'm hoping something similar exists.




L6 Presenter

Hi...You can review the traffic logs, search for the video session that ended, expand the log details and veirfy the start & stop time of the session and note the elapse time.  Once you have verified the session, note the application name.  Then navigate to Objects ==> Applications, look up the application and check its TCP timeout.  If the TCP timeout is close to the elapse time, then it is likely the application was terminated as a result of the TCP timeout for the app.   You can then modify & extend the default timeout for the app.  Thanks.

You can also do the same if you tap the traffic (using span-port) before and after the PAN and then check the generated PCAP in wireshark or tcpdump.

Hi, Thanks for the responses. As I search the forum I realized that I've posted the same question 3 times over the past year.  I know both of your suggestions will work, it just seems over labor intensive to me to do this every time we suspect a timeout from the PAs. How hard would it be for the PA Developers to add a log condition for when the connection is timed out by the firewall ?


log on session end (which is the default if you enable logging) should bring you this.

The problem here is to find out why the session ended and in my opinion using pcap will bring you the proofs you need of whats actually going on in the wire.

I do log on session end. There is nothing that states TCP TIMEOUT like in the ASA.

I do capture PCAPs but even there its tough to see the RST coming from the firewall. It's a needle in a haystack and I may be asked to do this a few times a quarter. When the firewall is creating an outage (intentionally) I think it should log it . No?

To preserve resource many applications will not end their sessions and the firewall has to end them via timeouts.  The most common app is web browsing where the browser typically will not waste resource to send FIN or RST to end their sessions.  Timeouts conducted by the firewall is quite common.

For video apps, if the control session is not transmitting regularly (keepalive) then the firewall may timeout the session thinking that it is an idle connection.  I recommend you test by launching a video session, monitor what apps are detected, and extended the timeouts for those apps.


The issue here is that a firewall will silently drop the session from the table w/o notifying either server or client.  Thus, if a client that opens long-lived connection via the FW and FW tears down the connection, next time client or server attempt to re-use it they'll be restransmitting for several seconds or longer (depending on the retransmit settings).

Is there a way to enable something on the firewall so it sends RST if/when it removes the session from a table.  Or, at the very least, send RST next time either party tries to communicate on the removed session...


I do not think paloalto will send any RST packets when we discard a session due to timeout or due to security policy deny. That is my understanding at least from this thread.

Yeah, it looks like it's a oversight...

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!