IKE Crashes and RA VPN issues on R81.20 Take 98

[Alex_Lewis]

We recently installed Take 98 on R81.20 and started having wide-spread problems with Remote Access VPN connecting. We also received a report from TAC Pro Support that an IKE crash was reported on our gateways, but unfortunately no additional details of the crash were provided. We did not see any signs that site-to-site VPN was affected, just RA VPN. After troubleshooting for a couple days, TAC informed us of a known bug and provided a patch that has fixed the issue. If you run into this issue after upgrading to T98, don't hesitate to reach out to TAC and ask about a patch for IKE crash.

[the_rock]

Interesting...I had not had that problem myself. Just curious, what was the actual fix?

Andy

[Alex_Lewis]

I guess the IKE crashing is not an issue for everyone. I had asked TAC about installing on other gateways when we upgrade them. There answer was "Unless we see the same IKED crashes or frequent significant RA VPN/S2S VPN tunnel disconnections, we don't recommend to install this portfix on all the gateways on T98."

[Henrik_Noerr1]

I wonder if Check Point knows what Important Notes are for?

Let me help; https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/Important-Notes.htm?tocpath=_____2

Some VPN issue was also reported in some of the latest threads as well, without anything in the important notes.

The extreme load on MLMs also was not present for a long time, I'm unsure yet if it has been added, as dates are not present when a new entry is added.

And yeah - don't upgrade to newest jumbos but let others take the hit 🙂

@the_rock You continuously for each jumbo advertise that this is now faster and more stable. Reporting it is now in your lab and stable, updating for 1hour 24hour and 48hours progress to stress how stable it is.

I invite you to not post these updates. I see them at best as ignorance, and at worst as false advertising in a let's be honest a non existing lab or a lab consisting of a VM with zero usage.

Thanks

Henrik

[the_rock]

I suppose everyone's experience is different. I can only speak for myself 🙂

Andy

[Henrik_Noerr1]

You are right, and it came out harshly - I am sorry for that.

I was trying (in a bad mood) to argue that the value of these tests show very little  in regards if of showing the issues that continuously keep popping up when we read down the forum posts.

My grympy mood was more pointed to, that we as customers need to have downtime, even though it is well known inside Check Point. "It only affects a subset of users, so we will not state it clearly as a risk in the upgrade information" is I think, a strange decision.

Let the customer evaluate the known issues. So does he hold a large RA environment, he could take a knowledgeable decision instead of feeling the pain and maybe skip upgrading.

What our own management would say, is that transparency is key.

[the_rock]

Dont worry man, life is too short to get offended, thats been always my motto, haha. I dont get offended to anything, or in human way lol. 

Anyway, I totally get what you are saying and I agree 100%. Its fair to say customers should be the ones to evaluate those things, because, lets be fair, production environment is hard to compare even to fully simulated lab, for the lack of better terms.

Cheers brother.

Andy

[Lesley]

I think then we can assume it is not important enough to put it on this list. I see recently stuff has been added so then we also assume Check Point is still aware of this page. If an issue is only affecting a small amount of customers it would make sense not to put it on this page. It could be that the Jumbo is good for 99% of the customer and some it can cause an issue. If they put everything on this page it will make unreadable and difficult to understand. 

Regarding the lab testing, I don't think it is needed to call someone ignorant. It is clearly stated it is in a LAB setup so everyone is aware of this. I think we all know the definition of a lab and that could not fully reflect a realtime setup. 

[genisis__]

Just a thought, guys.

I'm sure I mentioned about stability before and suggested to Checkpoint that it does not matter how secure a product is 'marketed' for, if the service suffers stability issues, the overall Checkpoint experience will be tarnished.

I would personally like to see a supported mature and feature train release. 
Example:
R82 - Feature release
R81.20 - Recommended Release
R81.10 - mature release (Support for 3 years, once version is deemed mature)

The positives of this:
Clients investment is protected while maintaining stability for the features they are using.
Certification investment could potentially be longer if you are certified against recommended, which last until mature train is expired.

[Ruan_Kotze]

Running into exactly the same problem across our estate.  Think I've got 4 separate PRO cases open:-)  TAC has not mentioned a fix - I will link them to this post. @Alex_Lewis do you mind privately sharing the SR number where TAC provided you with the patch?

[Chris_Atkinson]

There is a hot fix identifier mentioned in this thread over an earlier take FYI

https://community.checkpoint.com/t5/Product-Announcements/R81-20-Jumbo-Hotfix-Accumulator-take-96-ha...

[the_rock]

I was going to install jumbo 98 for the customer next week, but considering things said in this post, I think will stick with take 92 for now. 

Andy

[Ruan_Kotze]

Just FYI to all,

TAC has provided updated guidance which does not involve installing a patch.  Boils down to:
- disabling the "Perform an organized shutdown of tunnels upon gateway restart" option
- Creating a backup of and then removing the '$FWDIR/database/cookiedb.NDB' and '$FWDIR/database/deldb.NDB' files.

We're currently still in freeze and the issue is not business impacting so we will implement in the coming week. As always best to check in with TAC before performing this in your own environment.

Thanks,
Ruan

[CheckPointerXL]

Which model?