Maestro R81 has issues in Active/Active mode with Identity Awareness

[Danny]

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 

[Royi_Priov]

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:

1. my username (the "old one" on this IP) will be overwritten with your username.
2. a log message will be sent to the SmartLog - A secondary session request was received

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.

[Danny]

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

[Norbert_Bohusch]

Is maybe Identity Sharing involved from other gateways?

[Danny]

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.

[Benedikt_Weissl]

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

[Danny]

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