TCP TimeOut caused by the PA?

cancel
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.

Thanks,

Justin

15 REPLIES 15

Regarding your initial problem the timeout in PA should not occur as long as there are traffic being sent in either direction.

So a question here might be why this streaming app obviously stops sending packets on its own so a timeout occurs unless there is something else malfunctioning on the road?

Edit: Or is there some kind of "max life" timeout aswell (to deal with slowloris etc)?

Im not questioning the need for the firewall to timeout connections. It's a stateful box and cleaning up old sessions is a requirement. What often happens is firewalls dont understand a certain type of control traffic and enforce a timeout that is too short, terminating an active connection and causing the app to error out. That's going to happen on any firewall.

We as technicians need clear indications as to why a session was terminated. Just about every firewall out there will put spit out a TCP Timeout entry into some kind of log when this happens. If the log entry is there we will instantly know to create a custom application class with a longer timeout or with no timeout. Without the log entry we're left with more troubleshooting and time lost testing other theories.

I hope they fix this because its kind of a big deal. Also if they could fix reporting and add a good log viewer while they are at it that would be great. (in my best Lundberg voice)

L0 Member

Hello All, 

 

We have a similar issue to the one described on this thread where two endpoints (Client and Server) are trying to resume from a long period of inactivity but since the firewall had silently dropped the aged out session, the communication fails between the hosts and we have to manually restart the application. So the issue is, the firewall silently tears down the session once the expiration time is reached, without any whatsoever notification. As a result, the two endpoints attempt to resume from the last session, assuming the session is still active but the firewall discards the packets expecting to receive a new SYN message marking the start of a new session. My question is: Does PALO ALTO has any workaround other than increasing the Default session Timeout to a Max Value of 7Days?  Can the Palo acts as a proxy and offload the TCP session?

 

Thanks

rescuing the unsecured world, one bit at the time.

This is an age old discussion around application behavior... a couple things to consider, not all applications behave the same and I'm sure we all have war stories of sending a TCP-RST caused an application to blow up 🙂 so, no perfect answers for everything which is why if there is no traffic seen during the defined session timeout period it will be aged out and future traffic not starting with the appropriate TCP handshake will be dropped.

 

If the FW terminates a session then the reason it does so should be captured in the log at session end as described in this thread, see https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslo... for a run down (PANOS 8.1) of how the log is broken down. It is a little cryptic, but there is a parameter tracked for "aged out" of a session as a "reason" for session end.

 

As to what can I do? The first thing to check is to see if there is an App-ID for the application, Application Research Center would be the place to start.

 

If not, then you could create a custom App-ID for that specific flow and manage the timeout and other characteristics.

 

If all of that is too much to do right now then depending on your version of PANOS you can create a custom Service Object and manage the timeout value, https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-web-interface-help/objects/objects-services.html. This Service object could then be used in the specific security rule for that source(s)/destination(s) requiring the different timeout and/or other characteristics.

 

In general, changing the default UDP/TCP timeout is not a good idea as that becomes pervasive across everything which is probably not desired nor is it generally good security hygiene... hth

Thanks, @ddelcourt for the great input. I am wondering if there is a way to have the Palo Alto send a RST/FIN message to the endpoints to notify them when the session age-out instead of just dropping the session silently?!  I know you mentioned the alternative of creating a  custom App-ID/ Service object but if that requires to modify the normal behavior of the firewall then it is not an option in my case. Let me know, Cheers.

@NisterioHD I am certainly not an authority of all vendor FW platforms, but in general *most* security devices will drop aged out connections silently... 

 

I did a quick google search and found this KB article: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClUvCAK

 

Not a lot of detail, but it looks like the only way you can have the FW send a TCP Reset is if it triggers a Security Profile (threat) setting where this is an option... not everything yer looking for, but at least confirmation of what to expect...

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!