Snortv3 stream preprocessor drops and session tracking

[Kevin Marcan]

Hi Community!

               I stumbled across a weird one I am still diagnosing with TAC, still TBD if we are hitting a bug, but during my research on this I stumbled across a interesting topic.  

LINA and SNORT both manage there own session tracking / connection table.  IE show conn only shows the LINA table, not the SNORT table. 

More importantly, they each run there own timers.
LINA Default TCP Idle timeout: 1 Hour
Snort Default TCP Idle timeout: 3 minutes

While Snortv3 is meant to handle mid stream sessions, I have been able to mitigate some issues by aligning these two timers (increasing snort3 to one hour)

This is probably more of a Dev/BU level question, but if Cisco Firewall has two separate session tracking tables, would it not make sense to have the default values match so the tables are in sync with each other?   Vs right now you will have Snort3 sessions time out, while still being active in LINA, then snort needs to stand up mid stream sessions. And in our case occasionally drop packets / cause disruption. 

These issues could all stem back to a bug that we are still investigating, but I am still curious about the two state tables and not aligning the timers by default. 

[elsie78ash]

The disparity in default session timeout values between LINA (1 hour) and SNORT (3 minutes) on Cisco Firewalls is a known point of discussion. The core issue, as you've observed, is that a session can be active in the LINA connection table while already timed out in the SNORT table. This forces SNORT to re-establish a "mid-stream" session, which, while designed to handle such events, can sometimes lead to packet drops or performance degradation, especially if a bug is present. While the two components serve different purposes—LINA for core firewalling and SNORT for intrusion prevention—the lack of synchronized default timers can create a scenario where the security module is out of sync with the underlying connection state, potentially causing the exact disruptions you've encountered. Aligning these timers, as you've done, is often a practical workaround to mitigate these issues and ensure a more cohesive and stable connection management process between the two systems.