[j-nsp] Weird SRX flow timeout issue

[Tim Eberhard]

The SRX's behavior is if any packet passes over that session to reset
the timeout on that session, keep alive, data packet, whatever. As
long as it matches that session it will reset the timeout to the
default value and start decrementing again. So I'm not sure what you
mean when it says dropping tcp sessions with active TCP keepalives.

I've never had a problem where an application sent keepalives at a
rate greater than the default time out (say time out is 30 minutes,
keepalives are every 10 minutes). Then that session can last as long
as it wants. This is expected behavior.

-Tim Eberhard

On Mon, Nov 12, 2012 at 1:43 PM, Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> Tim Eberhard <xmin0s at gmail.com> writes:
>
>> While I haven't read this entire thread, it's worth mentioning that
>> this is a correct statement. TCP connections (by default) must be
>> initiated by a standard 3-way handshake. You can disabled this by
>> turning off tcp-syn-checking under security -> flow.
>>
>> I wouldn't recommend it however, as enforcing proper TCP state is
>> always a good security practice.
>
> Enforcing proper TCP state is certainly good security practice. Dropping
> a TCP session with active TCP keepalives is simply buggy and wrong.
>
> That does not have anything to do with the 3-way handshake or
> tcp-syn-checking which should be on.
>
>
> /Benny