Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
the_rock
Legend
Legend

R81.20 jumbo 90

I installed it in my lab today, no issues so far, but will give it 24 hours. I do see lots of fixes listed in the official doc.

Andy

 

https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/Take_90.htm?tocpath=_____6

0 Kudos
22 Replies
PhoneBoy
Admin
Admin

Looks like we have a fix for Blast RADIUS now 🙂 
https://support.checkpoint.com/results/sk/sk182516 

(1)
the_rock
Legend
Legend

I think that was included in jumbo 89?

0 Kudos
PhoneBoy
Admin
Admin

In JHF 89, we only had fixes for Gaia OS itself, not the other components.

the_rock
Legend
Legend

Got it.

0 Kudos
genisis__
Leader Leader
Leader

One thing to meantion - this fix is included in Take_106 for R81, however Take_106 also has an issue related to failover (I get R81 is EoL, but I think Checkpoint should fix this final Jumbo release, rather leave it in a broken state, and yes TAC case raise).
I totally understand that it would be more best effort, but come on, why issue a jumbo with a known issue and then just leave it.

0 Kudos
Lesley
Leader Leader
Leader

Just my 2 cents. If you release a new jumbo that will fix your issue it could be it introduces new issues for different customers. At one point it has to end. In this case a portfix based on best effort would make more sense to me. 

-------
If you like this post please give a thumbs up(kudo)! 🙂
0 Kudos
JozkoMrkvicka
Authority
Authority

Yeah, you see just fixes which Check Point mentioned in release notes. There might be many many more fixes which were just not mentioned for whatever reason, but are included in T90 🙂

Back to the topic, will have a look on each issue to be declared as fixed in T90. At least going to test Blast RADIUS fix.

Kind regards,
Jozko Mrkvicka
Thomas_Eichelbu
Advisor
Advisor

Hello Folks, 

i installed HFA 90 yesterday to get rid of this nasty 

[16 Nov 16:34:47][fw4_5];[vs_0];[10.X.X.X:52745 -> 1.1.1.1:53] [ERROR]: cmik_loader_fw_context_match_cb: match_cb for CMI APP 31 - DNS_DATA_SOURCE failed on context 201, executing context 366 and adding the app to apps in exception

messages!
after installing HFA90 they are gone! Great success!

But i had a weird issue,
i was installing this HFA90 via CPUSE on a remote GW (Cluster XL R81.20 HFA84) over VPN.
The Installation just started into a few % of progress and suddenly my access to this member stopped.
no SSH, no Ping, etc. not reachable over VPN anymore.
but i was able to reach the affected member over the Sync Interface of the active member.
HFA90 was installed successfully no issues after reboot.
The same issue happened on the the remaining cluster member as well.

did anybody noticed that before? Thats weird, because normally you stay connected on the installing member until its final reboot.

 

 

the_rock
Legend
Legend

I updated my lab actually over VPN as well, did not have such an issue. Though I was on jumbo 89, but not sure if that would make any difference.

Andy

0 Kudos
Thomas_Eichelbu
Advisor
Advisor

yes maybe its highly customer depending, or a solar flare just hit the earth, who knows 🙂

0 Kudos
the_rock
Legend
Legend

@Thomas_Eichelbu haha, maybe 🤣🤣

0 Kudos
JozkoMrkvicka
Authority
Authority

At some point of jumbo update, the installer stops cp services. It might be that the connection was cut during cpstop.

Always connect over serial connection or LOM 😉

Kind regards,
Jozko Mrkvicka
0 Kudos
Duane_Toler
Advisor

Yeah agreed.  I've had mixed results and had the same effect described in this thread.  Usually, tho, when that happens, I'm able to re-connect to the host via SSH directly to the public external IP.  My policies on customer gateways allow me to have that access from an external management host, tho (for this reason).

the_rock
Legend
Legend

Personally, and I say the same to all my colleagues, when we do any sort of upgrade for the customers, we always ask them to have someone on site if possible, because better be safe than sorry. It could be that 1 time out of 100 when issue happens and no one is there when you need them.

Andy

0 Kudos
Lesley
Leader Leader
Leader

I had same issues. 2 vsx gateways all good. Other units jumbo update at 14% stopped showing progress and unit was not reachable. I saw layer 2 connection so it was still alive. Update took around 20-25 minutes each unit. At one point I saw that arp entry was gone and I knew it was rebooting. It is not normal behavior but to be honest there was no impact or any issues during this. But I could imagine that a first timer would break a sweat maybe 😄

-------
If you like this post please give a thumbs up(kudo)! 🙂
Axel_Winterberg
Participant

Hi Thomas,

just updated a cluster with JHF T90, today. Same issue. After a few % of installing I had to reconnect.

Noticed it on both cluster member.

0 Kudos
the_rock
Legend
Legend

Did you open TAC case about it?

Andy

0 Kudos
Thomas_Eichelbu
Advisor
Advisor

Hello,

well no, no TAC case for this topic ... i am currently overloaded with cases and must prioritize on the most important problems ...
today i install HFA90 again on a single gateway again, lets see how it turnes out.


0 Kudos
Axel_Winterberg
Participant

No, Not for this issue. But after installing the JHF T90, we can only connect via local Admin to Smart Console.

SSH and https to the management server are working fine with RADIUS authentication.

But Login with Smart Console over RADIUS stops working. Opened a TAC case SR#6-0004135071

Log of RADIUS shows successfull Login, but we get error message "authentication to server failed"

In Audit Log we see, that the login is denied with "Wrong Password" !!!

0 Kudos
JozkoMrkvicka
Authority
Authority

Maybe related to blast-RADIUS articles sk182516 and sk42184?

There is a new registry integrated into T90 - require_message_authenticator which can be set to 1 (0 by default).

Kind regards,
Jozko Mrkvicka
0 Kudos
Axel_Winterberg
Participant

Hi Jozko,

I`ve seen this in the Release Notes for T89/T90 and have already set the parameter to "1".

Unfortunately, this has no effect on our issue. I have rebooted the server after save config.

But still the same issue. Have collected fwm debug and uploaded it to the SR. Waiting for Reply.

I have seen some error messages: 

request_handle_tick(rp=945f7c8): server is down. Try another if available.

RADIUS Servers Cannot Be Reached. Dropping Request

But I can still see the successfull authentication in the RADIUS Server Logging!!!

the_rock
Legend
Legend

Thats super odd @Axel_Winterberg 

It is indeed strange you would see proper authentication, but logs show requests dropped. Do you see the same in zdebug?

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events