Dropped "PSH-ACK" / Override Session Timeout questions

[T_Sonnberger]

Hello CheckMates,

we have recently moved our Client VPN Gateways from behind an OpnSense behind our Checkpoint Cluster.

Since then, one of our teams complain about connections resets of their applications.

I could see, that there are lots of "PSH-ACK" dropped out of state and after doing some investigation, I see that the default session timeout of OpnSense is set to 86400 Seconds vs. 3600 of Checkpoint.

I have then created a TCP Object, dealing with Ports 8440-8450 and set the Virtual Session Timeout to 86400 but the behaviour didn't change.

I have then checked via fw ctl conntab and could see, that the sessions were still created with 3600 sec.

<(inbound, src=[10.255.216.196,52396], dest=[10.49.2.138,8444], TCP); 1863/3015, rule=104, tcp state=TCP_ESTABLISHED, service=3600, conn modules: Authentication, FG-1>

So in the next step, I have created a dedicated object for port 8444 and now I can at least see, that the session timer is at 20879 sec.

<(inbound, src=[10.255.226.75,55032], dest=[10.49.2.138,8444], TCP); 20823/20879, rule=104, tcp state=TCP_ESTABLISHED, service=663, conn modules: Authentication, FG-1>

Question one:

Does the virtual session timeout for port ranges not work?

Since this is matching an "any service" rule - could it be that our high port object (TCP-1024-64535) interferes here?

Both, the small port range and the high-ports have a "match any" flag. As per the logs, the correct object matched, though.

Question two:

Why do I only see a session time of 20879 s in the conntab, while the time is set 86400 sec. in the port object.

Thanks in advance!

BR,

Tom

[PhoneBoy · Accepted solution]

What version/JHF level?
I could see potentially needing a more specific service definition for timeouts, but the "wrong" timeout for port 8444 is definitely wrong.
TAC case suggested here.

[T_Sonnberger]

Hi PhoneBoy,

thanks for the reply.

Version is 80.30 - Take 200

Regarding the timers, I will open a case with the support. Thanks for confirmation.

BR,

Tom