AWS GW Loadbalancer TCP stale session limit of 350 seconds

[Cyrill_Kaspar]

Hi fellow mates

At the moment we run a Check Point HA CloudGuard Geo Cluster R81.20 in our AWS environment over a AWS TGW architecture that checks on all east-west traffic as well as everything that comes from on-prem or over zero-trust appliances.

We consider changing the architecture to a scalable one with the AWS Gateway Loadbalancer.

There is one issue / sorrow we have: the hard limit in the GWLB of 350 seconds of stale TCP sessions. 

We assume that some of our legacy services / applications that moved to AWS would be affected by this limit. So we try to investigate if such traffic would be affected by the limitation. I found an ancient article concerning a similar topic but for CP R75.40 with "fw tab" command, that would probably help us detect such stale tcp sessions exceeding the 350 seconds limit:

https://networkengineering.stackexchange.com/questions/2829/find-idle-connections-in-check-point-fir...
fw tab -t connections -u -f | grep 86400 |awk '{ split($41,a,"/"); if( a[1] < 82800) print $2,$9,$13,$15,$41; }'

As the table has changed over the years, the printable positions are not correct anymore as well as the default TCP timeout of one day...

I have tried to adapt the command to our situation but I am not completely pleased with the output as it is not consistent:

fw tab -t connections -u -f | grep 3600 | awk '{ split($49,a,"/"); if( a[1] < 350) print $18,$19,$20,$21,$22,$23,$24,$25,$48,$49; }'
fw tab -t connections -u -f | grep 3600 | awk '{ split($106,a,"/"); if( a[1] < 350) print $18,$19,$20,$21,$22,$23,$24,$25,$105,$106; }'

My questions to you guys would be: did anyone had a similar challenge yet? How did you figure out if a GWLB with its limitations would fit into your environment smoothly?  Has anyone figured out a satisfying output with the "fw tab" command?

Looking forward to your reactions and have a great 1st of May (Thank God it's Tuesday)

Cyrill

[Shay_Levin]

Hello Cyrill,

It appears the community hasn't proposed any ideas yet. I'll look into it internally and keep you informed.

[Cyrill_Kaspar]

Hello Shay

Fantastic. Your support is very welcome and much appreciated!

Best regards
Cyrill

[Shay_Levin]

Run “fwaccel conns” for the accelerated connections and “fw tab –t connections –z” for the slow path.

Both commands will show you the info you want.

Duration is the time the connection is alive

Last seen is the time that passed since last packet.

So connections that are ideal for longer than 350 sec will have in the “last seen” column a number larger than 350s (note its not showing only sec, it will show min or hours )

Please inform me if this information is helpful. Additionally, if you have any interesting discoveries you're willing to share, it would greatly benefit other members contemplating a switch to GWLB

Thank you

[Cyrill_Kaspar]

Hi Shay

Many thanx for the commands and the explanation.

I think, I have figured out the filter parameters we need to identify the stale sessions that would run into the GWLB hard limit of 350 seconds:

fw tab -t connections -z | grep Estab. | awk '{ split($9,a,"/"); if( a[1] < 3250) print $2, $3, $4, $5, $9, $16; }'
This prints: [Source IP] [Sourec Port] [Destination IP] [Destination Port] [Expires] [Last Seen]

fwaccel conns | grep Established | awk '{ split ($17,a,"/"); if( a[1] < 3250 ) print $1, $2, $3, $4, $17, $15; }'
This prints: [Source IP] [Sourec Port] [Destination IP] [Destination Port] [TTL/Timeout] [Last Seen]

Looking up  https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_CLI_ReferenceGuide/Content/T..., I found in the legend for the command, that for "Expires" it states:  

How many seconds remain before the connection expires (based on the maximum expiration time).
Also, refer to the "Duration" column.
For example, 1990/3600 means:
The maximum expiration time is 3600 seconds.
If the connection remains idle for the next 1990 seconds, it expires from the Firewall Connections table

So I assume that to discover idle sessions that would run into the 350 seconds GWLB timeout, I would need do look after a value 3600 - 350 = 3250. If I understood correctly, everything below 3250 seconds would have been dropped already by the GWLB.

We will look into this in depth and will hopefully identify only a few legacy services hitting the hard limit. 

Best regards

Cyrill