Risks for disabling "Drop out of state TCP packets"

[kurtbuff]

We've just started implementing CP gateways, starting at our corporate office. We experienced issues with an old LOB app at our remote locations app that essentially does a two-way handshake then just uses pushes to keep data going to the server here. No keepalives, no fin, just data sent as gathered, which is fairly intermittent.

This engendered a lot of drops at the firewall as the state aged out. This in turn made the remote app very unhappy, and it kept crashing.

We tried lengthening the session timeout and increasing the state timeout, to no avail. Finally, CP support suggested disabling the setting for dropping out of stat tcp packets.

This does solve the problem, but it seems that doing so disables state entirely - no way that we can see to limit it to specific subnets/addresses/ports/whatever.

Is that really the case, and if it is, what are our risks in doing so? This is making me just a tad uncomfortable, and any thoughts appreciated.

One thing I've thought about is to put up a small unit (RPi or similar) in the subnets where the remote app lives and in the subnet for the corp server, and make them gateways for this specific traffic, tunneled over IPSec. I think that would work, but I'm not technically savvy enough to be sure about that. If there are other suggestions to mitigate this, or if my concern about disabling state are out of proportion to the risk, I'd love to hear about it.

Thanks,

Kurt

[PhoneBoy]

Disabling it globally is generally not recommended long-term.
You can disable it for a specific connection by following this procedure: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[lnxman]

Thanks for the reply, I am the Systems Administrator that was working on fixing this issue with Kurt and I did find this SK but I could not get it to work properly so I ended up globally disabling out-of-state packet drops yesterday to resolve the issue. Can you give me any pointer on why my attempts at this configuration did not work?

These were my attempts at allowing out of state traffic to 10.5.40.21 on port 9005

/* Start of INSPECT modification - sk11088 */

deffunc user_accept_non_syn() { (dst = 10.5.41.21) };

deffunc user_accept_non_syn() { dport = 9005 };

troublenet={ <10.4.41.20, 10.4.41.50> }; deffunc user_accept_non_syn() { (src in troublenet) };

troublenet={ <10.4.41.20, 10.4.41.50> }; deffunc user_accept_non_syn() { (dst in troublenet) };

/* End of INSPECT modification */

[PhoneBoy]

What precisely happened when you tried this?
Also what version/JHF level?
It's possible you may need to engage with the TAC here.

[lnxman]

There was no change, the packets kept getting dropped for being out-of-state due to "First packet isn't SYN" because our point of sale vendor does not conform to TCP RFC standards. I did engage the TAC and was able to get one of the Check Point customer success engineers to provide the global option change, but this is not a great option for us so we are trying to figure out how to get the user-defined rules to work properly. We are a new customer with Check Point so we are on the smart-1 cloud on version 80.40.

[PhoneBoy · Accepted solution]

In the case of using Smart-1 Cloud, yes, they have to implement this change on your behalf.
Depending on the version of gateway used, they may have to edit a different file to implement this change. 
In any case, this issue should be escalated with the TAC.

[JozkoMrkvicka]

What is the purpose of the firewall ?

To allow something which is not correctly recognized by the firewall ?

Isnt it FIREWALL itself which should drop such invalid traffic ? Why such a traffic should be allowed by workaround(s) ???

Traffic is dropped because app developers didnt follow RFC TCP standards.

The issue is not on the firewall.

The ball should be on app side to correct 3-way TCP handshake. Full stop.

I was involved in many "firewall issue" related to "First packet isnt SYN". TAC indeed suggested that there are dozens of workarounds how to allow such traffic, but also confirmed that traffic is not following TCP RFC. Now, the app developes must repair/fix/patch their libs to follow TCP RFC.

[lnxman]

While I do not disagree with you this is a point of sale system and how we make our money so I must find a solution since this vendor will not fix their code. This codebase looks like it was written back in the '80s and never updated, the intent looks like they were trying to save on dial-up bandwidth. I know just crazy...Welcome to systems administration 😠

I appreciate the community assisting me with this issue, this was very impactful for us.

[the_rock]

I agree with everyone who responded. Its NOT recommended, BUT you can always set up rules to block whatever you wish to block. I seen people do that before and it works, but again, not really recommended.