Contract Renewal Issues

[biskit]

Hello everyone 😀

I find often that the license status in R80.x is inaccurate.  Is this a common/known problem?

Today I have the latest example of this.  The customer has renewed NGTX.  I've updated the contract on all servers, and depending where you look you get differing statuses. 

As far as I know in R80.20 there are 3 places to check the license status.  These are:

1. Manage Licenses & Packages (aka - SmartUpdate) (from where I updated the contract)
2. Gateway summary - Device & License Information
3. CLI - #cplic print

I would expect these to all line up perfectly. 

But they don't.  

Why not??

I updated the contract file yesterday, and by way of example with one of the clusters, one member in #cplic print shows the updated renewal date 1 AUG 2020.  The other cluster member still showed the old date of 1 AUG 2019.  As I have the magic tick box ticked which automatically checks and updates I thought I'd leave it over night and check this morning.  Today that member is up-to-date.  Great!  But there is still a problem...

To illustrate this I have some screenshots from the aforementioned cluster member.

1) #cplic print.  Notice all blades are good until 1Aug2020 - including the URLF blade.

2)  SmartUpdate.  Again, notice all blades are good until 1Aug2020 - including the URLF blade.

All good so far!

But then....

3)  the Status view from SmartConsole show some blades updated, and others not.  So what's going on??

When I go to install the policy I get the same warnings...   highlighting the URLF blade again as one example.

So, any ideas why SmartConsole still moans about contracts about to expire, when SmartUpdate is up-to-date, and the gateway has the up-to-date contract on it?  Where is SmartConsole looking for this info?  It obviously isn't the same place SmartUpdate references.  

Thanks,

Matt

[Tommy_Forrest]

While I don't proclaim to know the mechanics behind the why - it is a completely normal behavior.

If you wait it out, it'll go green after the expiration date (assuming that you have valid contracts).  On expiration, the gateway and/or other devices will check in with the mothership, see the new contracts and then you'll be all set.

It freaked me out too the first time I went through a contract renewal period.

[biskit]

Hmm, it's just so odd how there's no consistency to what it displays.  The contract is already updated, so why show some blades correctly and other blades not?  On the other cluster member it shows different blades covered and expiring soon - even though once again everything has the new contract on.

It makes no sense.  The contract applied to the gateway clearly states the expiry date, so how can SmartConsole just randomly ignore parts of it?  In my opinion, "Waiting it out" is an unsatisfactory answer.    😕

[Daniel_Taney]

I agree it doesn't make sense, but I experienced the same issue with our last renewal. After the expiration date, all the expired warnings cleared out and the proper contract dates showed up for all blades. The best we could get was that it was a cosmetic issue and not to worry about it. 

[biskit]

While I'm sure you're right, and it might rectify itself on 1st August, it is clearly not joining all of the dots somewhere along the line, so what happens on 1st August if it doesn't magically sort itself out, and the blades stop, and the customer is compromised as a result.  

The new contract is on now.  It shouldn't be flagging random blades as not being up to date.  The random nature of it gives me little confidence that it is actually all OK.

BTW - I have this raised with Account Services too, but I know this forum responds faster and might have had a solution.  Account Services haven't responded to the SR yet (so much for the SLA of a 4 hour response!) but when they do I'll update this post with the fix.

[Daniel_Taney]

I had similar concerns. In my case, I generated All-In-One Evaluations for those Gateways and had the license files ready on standby just in case something went sideways. 

Again, I understand that's probably not the answer you're looking for. But, it may not hurt to have them just in case!

[PhoneBoy]

It's probably worth a different TAC case (not with Account Services) to understand why SmartUpdate/CLI/SmartConsole are showing different results.

[biskit]

Update on this case...  A few very helpful Check Point people saw this and contacted me offline to help.  After lots of trying different things and capturing debug info, we got there.  One of the gateways was failing due to something on Check Point's side.  Someone did something with the CK of the gateway and said "try again now..." and hey presto, it worked!

Some of the other gateways were still failing and turns out it was because they didn't have access to sync up with Check Point's cloud.  The gateways in question are internal and air-gapped, so didn't have Internet access.  So even though you pay your money, download the new contract and apply it via SmartUpdate, it has no effect until the gateway has "checked in" with Check Point cloud.  I'm still questioning with CP how we activate contracts for air-gapped gateways that cannot be connected to the Internet.

[PhoneBoy]

My understanding is that you can download the contract file offline and apply via SmartUpdate in this case.

[biskit]

That was my understanding too, and always used to be the case but I suspect CP have twiddled with something recently?  In my recent case, even with it downloaded and applied via SmartUpdate, and #cplic print  showing the new contract date, other places such as the Device & License Info page in SmartConsole, and #cpstat appi -f subscription_status showed certain blades (such as App Control in this case) NOT updated, and it wouldn't actually update and work until it had sync'd with the cloud.  I'll pay special attention to this next time I have a renewal coming up and see if the same applies.

[PhoneBoy]

As I originally said, this probably needs a TAC (not Account Services) case so we can see what the issue is.

[biskit]

Yep.  I raised a TAC case and was told it was cosmetic and he closed the case without further discussion.  Frankly this is not a satisfactory answer, and when some blades show updated and others don't it doesn't give any confidence that it will work on the strike of midnight at renewal time.  However from this thread I also had a couple of people from QA and R&D getting involved and they spent several days working on this with me giving amazing support.  It's all working now, but there's still a question mark over how new contract files are actually activated on gateways without Internet access.  And the consistency over what is displayed in the device status page (two members of the same cluster showed different results after the contract had been updated - some dodgy coding that needs sorting out!)  One for everyone to be aware of, and I'm be interested to know if anyone else has the same problem in the future.   The other CP people who helped me on this case have said is that gateways need Internet to sync to the cloud and activate the license, but that doesn't answer how SCADA and other non Internet facing gateway work come renewal time.  On current evidence I think CP need to re-think the whole "must sync to the cloud to activate" idea - or go back to offering a working alternative of applying the contract file manually offline, as always used to be the case.

[PhoneBoy]

If the issue is truly cosmetic, there should be an SK saying that, which I don't believe there is.
There are plenty of other non-SCADA instances where offline activation is needed.

[Carey_Page-Sin1]

To add to this as a me-too story - We also had the same issue at our last contract rollover. We went through all the usual processes to ensure the correct updated contract file was installed and the gateways had Internet access. Contract info looked fine. The IPS blade was showing the new expiry, but Anti-Bot, URL Filtering and Application Control stubbornly indicated as 'about to expire'.

We were also told it was cosmetic and to wait it out. Though also were offered the option of applying an evaluation license to cover the rollover date. It is apparently expected behavior with Enterprise Based Protection contracts, as per sk105057 (this SK has only recently become public).

We decided to wait it out, and discovered it was definitely *not* cosmetic. Our URL filtering and Application Control blades indeed disabled on the rollover date. The notable effect was these blades failed open, and that websites that are normally blacklisted became accessible.

We applied eval licenses to all but one of the affected gateways which re-enabled the blades. Just out of curiosity we left one gateway without an eval license, to see if it self corrected over the day. Given being in NZ we're GMT+12 I wondered if the centrally managed rollover dates were GMT based and not accounting for local timezones.

Indeed the next day that gateway self-corrected, and started showing the new contract expiry, with the blades re-enabled. I removed the eval licenses for the other gateways and confirmed they were also now all showing the new contract expiry.

I provided this feedback to TAC, though there didn't seem to be much interest in further investigating.

[Patrick_Tuttle1]

Looks like this is still happening in 2020 on R80.20 and 30.

We have clusters and the secondary is ok with all blades renewed but the primary in both cases is showing the old lic.

CPLIC shows correct info, Smartupdate shows correct info but Smart Console does not. 

Pushing policy creates the error as well. Contract about to expire.

Might be cosmetic but still not right.

[PhoneBoy]

Still worth a TAC case, even if cosmetic.

[Patrick_Tuttle1]

I thought this was TAC 😉

[Tommy_Forrest]

I love Check Point, but man.  If I could wave a wand and make licensing disappear, I would be a happy guy.

Every time our renewal comes up I *always* have a handful of gateways that won't place nice and someone in Accounts has to get involved.

I've got 3 out of 4 Cloudguard gateways thinking our support contract expired yesterday.  But licensing is showing the correct date.

It's really annoying.

[Patrick_Tuttle1]

Its more than annoying in our place. Very difficult to explain to upper Management why after spending 1/2 Million for renewal every year, that I have spend time to get things like this resolved.

[Patrick_Tuttle1]

and just found out that some of the errors were cosmetic and cleaned up overnight but others have expired the IPS blade.

[Tommy_Forrest]

Is it showing that the contract is expired?  Or is it saying IPS isn't responding?

If not responding, try pushing threat policy.  That's fixed that error for me in the past when it's come up after license renewal.  If they're still showing expired, call account services and get them to take a look at what's up.

[Martin_Raska]

From today's renewal at the customer side, this is still happening... OMG R80.10

[Martin_Raska]

Is there anybody who knows how to delete cache on SMS except this - sk105757?