gateway identity issues since apply r81.20 HFA84

[D_TK]

Is anyone else having identity issues since applying this HF?  Identity has worked relatively problem free in the past, but since applying this HF a few weeks ago, i find myself rebooting gateways every few days because they have no new user/ip associations.

I have two identity collectors - both are configured to push ident to all gateways (pseudo HA per the guide).  When my issue is occuring on a specific gateway, from the collector standpoint, it's happy.  gateway is green in the UI, and the "events in the last hour" is incrementing normally.  Version of the IDC is: 81.069.0000.

Gateways are all clusters.  When the issue is happening, there are no new user/ip associations.  sometimes, but not always, the pdp processes are pegging the CPU.  the simple fix is the failover to the standby member, and have the users do a quick lock/unlock of their desktop - problem solved, new associations populated.  I'll then reboot the wonky member and then ensure its identity associations are up to date before putting it back as primary.  This issue doesn't happen to all gateways at the same time.  I'll resolve one today, and maybe a different location the next day,...

Is there a better way to stop/start all of the identity processes on a gateway than a reboot?

Anyone else experiencing this behavior?  It definitely started with the latest HF as this behavior has never happened in the past.  i'm tempted to apply HF 89 even though it's not recommended yet to see if it resolves this issue.

Thanks all.

[Lesley]

If you hit these 2 sk's below you need to update towards 89, so please check

https://support.checkpoint.com/results/sk/sk182635

https://support.checkpoint.com/results/sk/sk182220

[D_TK]

Thanks Lesley.  Do you know if this behavior was introduced by HF84?  I now need to decide if i want to remove this HF, or apply a currently not recommended HF.

[Lesley]

I don't know that sorry. Maybe first check if you match the symptoms before you proceed. Then it is worth thinking about it.

 

[the_rock]

Yes, take 89 is your answer.

Andy

[D_TK]

stable?  i'm currently in seasonal lock down starting 10/1.

[the_rock]

I can only speak for myself, as have not had any customers install it yet. In the lab, so far, seems super stable.

Andy

[D_TK]

fair enough.  i'm thinking of going straight to the gateway with 89 and leaving management at the recommended 84 - thoughts?

[the_rock]

100%. In my 17 years dealing with CP, I had NEVER installed jumbo on the mgmt or ever suggested it to any customer. Okay, Im lying...technically, since standalone is considered mgmt (sort of), then I guess I did : - )

Anywho, in distributed environment, I never bother installing jumbo on mgmt, ONLY gateway(s)

Andy

[Lesley]

This is not right in my opinion. This is also documented:

https://support.checkpoint.com/results/sk/sk98028

The Jumbo Hotfix Accumulator can be installed either on Security Gateway, or on Security Management Server / Multi-Domain Management Server in the environment.

However, to ensure that all the issues listed for the Jumbo Hotfix Accumulator are resolved, it is strongly recommended that the same Jumbo Hotfix Accumulator is installed on all Security Gateways and Security Management Servers / Multi-Domain Security Management Servers in the environment.

Also not updating management systems you have higher chance of vulnerabilities to be still active.

I don't see a reason not to update.

[the_rock]

Personally, I never found any value whatsoever installing jumbo hotfix on management server, but thats just me. But, to keep it consistent, I agree its always good idea to have all the "entities" on the same jumbo.

Andy

[Nik_Bloemers]

I don't agree, there are loads of management fixes in JHF's. Just take a look at the Resolved Issues list and type 'management' in the filter field. There are hundreds of fixes for management/logging/SmartConsole issues (for R81.20 I quickly count about 360 fixes when I filter in the CSV), plus lots of new gateway features that ONLY work when you also update management. In my opinion it is best practise to keep the JHF versions either the same or at least close.

[the_rock]

Thats totally fair to keep them at the same level, no argument there. But, take for example Smart-1 instance...every time I called TAC for multiple clients to ask them JHF level, it was always AT LEAST 5 levels less than the gateways and it still worked fine, so I never pressed them to have it updated, as its done by CP anyway, on schedule.

Best,

Andy

[Alex-]

If this is a documented issue, the best approach is to follow the relevant SK/TAC, just for information we had to script a daily refresh of PDP/PEP in some implementations where identities would fail randomly, until fixed by some hotfix.

cat $FWDIR/lib/nac_tables.def | grep dynamic | cut -d ' ' -f1 | grep -v idp | awk '{ print ("-t "$0"")}' ORS=" " | awk '{print "fw tab " $0 "-x -y"}' | bash ; fw kill pdpd ; fw kill pepd