topic Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby in Firewall and Security Management

R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Fri, 25 Nov 2022 10:41:17 GMT

ClusterXL Appliance 3800, before R81.10 T78

Update yesterday to R81.10 T79, Update without Errors at all,

active Member works fine, no problem in operations - but standby goes in error

I have seen this error before in previous posts for other Takes ...https://community.checkpoint.com/t5/Management/Anti-Bot-amp-Anti-Virus-IPS-update-error-on-Standby-Member/td-p/55314 and others

rollback, wait for fixup, ignore?

Thank you

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

Lesley — Thu, 24 Nov 2022 12:14:57 GMT

Hey Dirk,

Depends, if the upgrade just finished it needs some 'time'. In this case I would reboot the stand-by unit + mgmt.

If this not helps there is a SK that the management is not showing the correct status.

Maybe check after reboot if it is really the case you cannot reach updates.checkpoint.com

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 12:16:20 GMT

Thanks Lesley,

no, ... update a few hours before, extra reboot just to look at it ...

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 12:32:58 GMT

from active Cluster-Member access ok (Gaia)

from standby no access

ofc same DNS, Proxy (no Proxy) in Cluster for all members ...

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

Lesley — Thu, 24 Nov 2022 12:35:58 GMT

Maybe this SK will help:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk43807

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

the_rock — Thu, 24 Nov 2022 12:50:04 GMT

I cant comment for production environment, but I did this in the lab recently and never saw this problem for the cluster.

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 12:52:47 GMT

I'll try ... skeptical: until yesterday with T78 everything was still running

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 13:00:28 GMT

thank you Rock, I have removed the warning in the post and will keep you up to date on what it was. ... I will also not make a rollback for now

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

the_rock — Thu, 24 Nov 2022 13:07:12 GMT

@Lesley gave good reference sk, but personally, I dont believe this is a bug. Maybe worth troubleshooting with TAC.

Andy

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

Lesley — Thu, 24 Nov 2022 13:31:55 GMT

Final idea, perform fail-over and let it do it's updates (if even possible). If it can do updates it is related because it is the stand-by if not something is going on with this member. If the update is a success make it stand-by again and watch what the effect is and if the issue reoccurs.

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

the_rock — Thu, 24 Nov 2022 13:34:09 GMT

very logical point!

Re: Warning! R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 14:13:15 GMT

Lesley, thanks for input

yes the thought I already had in mind 😉 ... but I work remotely ... I assume in any case that the session goes away, if not come back ... increased risk for me ...

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

nooni — Thu, 24 Nov 2022 14:15:58 GMT

Probably same result but sometimes SmartConsole can fool you with "cosmetic errors"

Check status at CLI on gateway:

cpstat antimalware -f update_status

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Fri, 25 Nov 2022 10:04:28 GMT

@nooni ... no cosmetic errors from console view ... was true no access from Gaia and CLI

thx for your input, the cpstat is ok now because the problem was temporarily solved by failover.

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Fri, 25 Nov 2022 09:01:29 GMT

So, ... I took the risk of a failover, session was gone, but came back after about 20 sec 😥 (different from usual, there was no interruption of the sessions...)

After the fail over everything was green (maybe I didn't wait long enough), the updates (IPS, anti-BOT) were also pulled now, but:
after a re-fail-over (back to the initial position) I have again on standby no connection to the CP Cloud ... i'll turn back again and look at the other cluster member regarding access ...

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

the_rock — Thu, 24 Nov 2022 15:33:16 GMT

Maybe compare output of below commands on both members:

ip r g 8.8.8.8

curl_cli -k google.com

Andy

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

Naama_Specktor — Thu, 24 Nov 2022 15:50:23 GMT

@DirkB

Hi 🙂

My name is Naama Specktor and I am checkpoint employee.

if you opened a TAC SR , I will appreciate it if you share it with me here or via PM.

Thanks!

Naama

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 17:55:40 GMT

@Naama_Specktor Thank you for the offer ... but I'm a "bit up in the air" with TAC ;), because we have no partner at the moment and the new contracts still take some time ... I will test a few more things and report back here.

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Thu, 24 Nov 2022 18:26:01 GMT

So, currently I get for the active and standby member for the route on Google DNS the external IF as destination and then "cache".

For the test on the Google site I get only on the active member a response (301 Moved), on the standby comes error (6) "could'nt resolve".
If I do a failover, this behavior persists, meaning the active member can resolve what didn't work before (as standby).

The standby can't resolve what work before (as active).

Basically, this behavior was already observed in Gaia when checking the updates ...

Re: R81_10_JUMBO_HF_MAIN_Bundle_T79 Problem with Standby

DirkB — Fri, 25 Nov 2022 09:03:26 GMT

The problem is recurring and moves to the standby member each time a failover occurs.

It will probably be best if i roll back the update so that I can see if without the update everything runs normally again as before (?)