broken tcp half-closed functionality

Henrik_Noerr1 — Tue, 24 Jun 2025 09:41:41 GMT

Hey,

We have general issues with the way Check Point deals with TCP Half-Closed timers.

Today Check Point as the only vendor I know of follow the general TCP timer for FIN_WAIT timers. So with default timers that that would be 3600s.

This brings an issue if for some reason the server does not reply to a FIN from the client, or the packet is lost somewhere.

Best seen in this diagram by Palo: https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-networking-admin/session-settings-and-timeouts/tcp/tcp-half-closed-and-tcp-time-wait-timers

So if a client sends a FIN through a firewall, it goes to "Source FIN" state - seen with ie "fwaccel conns" - but still with a 3600s timer. Only when and if it sees the server FIN ACK it goes to "Both FIN" with a 5s timeout by default.

Because Check Point holds the connection for an hour the risk of state errors is massive, specially for connections with a proxy, loadbalancer or other device with a lower timer. The Check Point firewall will see a SYN packet for a new connection, because all other devices have correctly aged out the connection. Waiting one hour for the last server FIN is exceedingly high.

Palo uses 120s and allows individual configuration of tcp service easily.

Cisco ASA uses 600s and allows individual configuration of tcp service easily.

Forti uses 120s and allows individual configuration of tcp service easily.

So what can we do with Check Point? I can find sk137672

So we can set the timeout globally on a firewall, but only by actively maintaining a kernel paramater 😞 - and using the horrendous gui/dbedit tool - and remember to deviate from the Check Point default when creating new firewalls, migrating and upgrading.

Alternatively the timer can be changed by changing the default tcp timer in SmartConsole for the service - which seems like a very weird decision - Why deviate from the agreed RFC timers to control the half closed timer?

All in all - I guess I have the solution - using kernel parameters and guidb - and meanwhile try to explain customers and management why we sometimes causes incidents, and why we spend more time maintaining this platform than others... I am simply advocating for Check Point to give us better options (and better defaults). Why not integrate this simply into the service object.

Rant out 🙂

Henrik

Re: broken tcp half-closed functionality

G_W_Albrecht — Tue, 24 Jun 2025 11:01:28 GMT

Maybe do a RFE ?

sk71840: How to submit a Request for Enhancement (RFE)

Re: broken tcp half-closed functionality

PhoneBoy — Tue, 24 Jun 2025 15:05:45 GMT

Something that was discussed at CPX 2025 that's worth mentioning here: we're trying to eliminate the need to use expert mode.
This means things like kernel variables should be configurable from things that don't require expert mode.
It also means changes like this will persist across upgrades.

@Tomer_Noy I assume we are trying to eliminate the need for using guidbedit also?

topic Re: broken tcp half-closed functionality in Firewall and Security Management

broken tcp half-closed functionality

Re: broken tcp half-closed functionality

Re: broken tcp half-closed functionality