topic Re: sk11088 make the out of state packet not drop ? in Hyperscale Firewall (Maestro)

sk11088 make the out of state packet not drop ?

cphseric — Thu, 15 Dec 2022 13:58:27 GMT

As the statement in the subject, for some reason, if application connection traffic traverses FW and has TCP long connection over the TCP session timeout setting in the FW, then the connection will be killed and dropped stateless packet by FW, correct?

I found a sk11088 which says the issue had been fixed if upgrade to the target JHF version. Does that fix mean even if the TCP session timeout is exceeded but the packet will not be dropped ? If not , what means for the fixed mentioned in the SK11088?

SK11088,

Symptoms
SmartView Tracker may show multiple logs for TCP packets being dropped as "TCP out of state" packets with the following TCP flag:
SYN packet for established connection
"First packet isn't SYN" drop logs in SmartView Tracker for TCP traffic.
Cause
Some applications do not maintain proper TCP state.

Solution
This problem was fixed. The fix is included starting from:

Jumbo Hotfix Accumulator for R81.10 starting from Take 14
Jumbo Hotfix Accumulator for R81 starting from Take 51
Jumbo Hotfix Accumulator for R80.40 starting from Take 150
Jumbo Hotfix Accumulator for R80.30 starting from Take 241
Jumbo Hotfix Accumulator for R80.20 starting from Take 208

Re: sk11088 make the out of state packet not drop ?

the_rock — Thu, 15 Dec 2022 14:35:26 GMT

Its not recommended to have that option unchecked. To answer your question, you are correct. Personally, I would confirm why those drops are there in the first place. Run fw monitor and observe the packet flow.

Re: sk11088 make the out of state packet not drop ?

Chris_Atkinson — Thu, 15 Dec 2022 14:40:10 GMT

Which platform are you using and what software version, hopefully with a current JHF deployed?

Refer also sk180364

Re: sk11088 make the out of state packet not drop ?

PhoneBoy — Thu, 15 Dec 2022 15:58:41 GMT

There were specific circumstances where we were dropping things as “out of state” that we should not have dropped—this is what the fix is for.
If you want to disable state checking for a specific known, trusted traffic flow, the procedure in sk11088 is what you will need to follow.
Otherwise, you can disable state checking entirely in Global Properties (Not recommended).

Re: sk11088 make the out of state packet not drop ?

cphseric — Fri, 16 Dec 2022 07:10:19 GMT

Thanks @PhoneBoy, @Chris_Atkinson , @the_rock for your replies. I have several virtual FWs with Gaia version 80.30SP. I want to know if upgrade to the target JHF version described in sk11088 and TCP long connection packet won't be dropped by FW even if they are out of states ?

If not, @PhoneBoy as you mentioned, "There were specific circumstances where we were dropping things as “out of state” that we should not have dropped". Can you please expand a little more on this 'specific circumstances'? Do you mean the connection is still in FW state table but the packet of this connection was dropped ? The sk11088 says the cause is 'Some applications do not maintain proper TCP state' . it seems too simple and summarized. Any example to describe more details?

So, normally I know the stateful inspection should be enabled as default and recommend. Does that mean if any TCP long connection traverses FW must has keep alive mechanism and make sure the idle time won't exceed the value set in the FW so that it won't have out of state packet, otherwise , it's the fault of APP and needs to be fine turned to be survived under stateful FWs?

Re: sk11088 make the out of state packet not drop ?

Chris_Atkinson — Fri, 16 Dec 2022 09:28:20 GMT

R80.30SP is a different code branch with different JHF, this article doesn't apply to those.

Re: sk11088 make the out of state packet not drop ?

PhoneBoy — Fri, 16 Dec 2022 15:37:32 GMT

To get a precise explanation of what the “fix” refers to in sk11088 entails, you’d probably need to engage with the TAC.

Stateful Inspection firewalls have been a thing for nearly 30 years now…and yet, applications are not always designed with them in mind.
If it’s a third party application, it may not always be possible to “tune” the app appropriately
(particularly if it’s a legacy app).
Which means you might need to disable stateful inspection for a specific flow.