- Products
- Learn
- Local User Groups
- Partners
- More
CheckMates Fifth Birthday
Celebrate with Us!
days
hours
minutes
seconds
Join the CHECKMATES Everywhere Competition
Submit your picture to win!
Harmony Mobile 4:
New Version, New Capabilities
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Check Point R81 with JHF 36 is Check Point's current widely recommended release for new installations.
So we set up a new Maestro R81 JHF 36 single-site installation three weeks ago (2x MHO-140 on R80.20SP + 2x 7000 Appliances on R81 JHF 36). As soon as we set both 7000 appliances active then Identity Awareness shows several IA logout issues that force us to set one 7000 appliances to down state via cluserXL_admin down
.
SmartView log shows: "User Logout: A secondary session request was received from the same IP. This caused logout of the current session"
sk131792 does not apply as we don't use an Identity Collector. We have about 5k identities from IA agent users, 5k from IA agent machines, 2k from MUH agents and 50 identities via captive portal.
$FWDIR/log/fwk.elg shows: "[Date][fw4_8];[vs_0];[x.x.x.x:64567 -> y.y.y.y:443] [ERROR]: idapi_load_data_impl: session i d string not found in client_db, although ip x.x.x.x was assigned to it"
Because of performance issues we really need the secondary 7000 appliance to be active as well asap, which is also what Check Point's HyperScale is all about >> adding more power with more appliances.
A service request was opened and escalated two weeks ago.. still no solution. CP Professional Services is involved and mentioned a similar issue in a previous version.
Does anyone else experience the same issue? Was anyone able to fix it?
@Laszlo_Csosza , @Anatoly, @Tom_Hartig, @Uri_Yahalom , @adam_hajoj , @Orel_Vanounou , @Lari_Luoma , @FabianWrba , @Vitaly_Uritsky
Hi @Danny
I will first explain in general the reason "A secondary session request was received ..." :
Most of our identities are saved one per IP - which means, if I will be associated to IP 192.168.1.100, and your user will be associated also one hour after with same IP - the following will happen:
This is how the product works by design.
The SK you have mentioned tries to explain this message with the most frequent scenario which cause it - service accounts, which Identity Collector and AD Query really sensitive for them.
Now, we will need to understand what is the flow which happens in your environment which cause this error to be presented.
As for the errors in fwk, basically what they mean, without reading the full debug, is that there is a mismatch in IDA tables on the enforcement side. As this is cluster environment, I would recommend applying sk170516.
As for the support ticket handling, I will appreciate if you could provide me with the ticket number and I will check it with TAC guys to understand the delay.
Hi @Royi_Priov ,
we already performed the procedure described in sk170516 on August 19, as mentioned by me in the SR.
I just sent you SR nummer, please have a look at it. Currently TAC is requesting to perform the same procedure again while we already provided the result of this routine two weeks ago.
Regards, Danny
Is maybe Identity Sharing involved from other gateways?
It's really just the two 7000 appliances working as a single security group. So there is no identity sharing. I just got the info that R&D is already investigating a same type of issue for another customer as well.
I had a somewhat similar problem in a big enviroment with 2x 7000 Appliances, it turned out to be the number of open file descriptors.
Search for "number of open file descriptors" in sk88520, this solved the problem
Thanks, in our case rebooting the entire security group, installing R81 JHF 42 and changing the distribution mode of the relevant internal interface from policy (default) to network helped.
This also fixed a nasty boot-loop issue we experienced in between. sk169515 wasn't of help, as our symptoms were these:/var/log/reboot.log continously shows:
Fri Sep 10 17:13:18 CEST 2021 Reason: reboot_with_log : Rebooting local blade (global context database was modified) Type: configuration
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY