Most URLs categorized as X-VPN this morning

[Marcel_Gramalla]

Hi,

we encountered a big issue this morning as nearly all URLs were categorized as X-VPN application which is blocked in our rulebase because of the category (Anonymizer) and it's also set to critial risk.

Did you encounter the same and is there any official statement? It's obviously an issue with the database and the first time we see such an issue. 

[Jennifer_Wilson]

Cheers for that 796570686578!
Following SK182202 instructions on Gateways that were already showing as having upgraded to the new DB worked great..
No more X-VPN showing in logs a couple of minutes after running the instructions.
Regards,

Jen.

[kale24 · Accepted solution]

All gateways had the new file yet we still had to create the manual whitelist for X-VPN.
I then completed the SK article on ALL gateways (even ones not using the application blade) and only then did we stop seeing logs.
I will monitor to see if anymore appear but the trick is going through the SK regardless of the file date.

[emilpersson]

All but two clusters got updated and automatically started working for me, the last two as you said stated correct version, but i still had to follow SK to get them working.

:appi_version ("110424_1")

[Pedro_Madeira]

I confirm this information from @kale24 . For some customers, I had to complete the SK regardless of the fact that the gateways already received the updated application control update version.

Only after going through the SK (no policy installation required at the end) I was able to solve the issue for a handful of customers.

Hope this helps other people.

Pedro Madeira

[majkel]

Any info from CP reg this incident ?

[K_R_V]

they created an SK article : https://support.checkpoint.com/results/sk/sk182202

The article states the package was released on April 8th, but it was only downloaded on April 11th.  ( potential inaccuracy because the gateways checks each 2 hours for an updated package)

[Nigel_Costar]

Yes... So I suspect there is some smoke and mirrors going on here, be nice of CP can come clean on this. there was an update to SK182202 asking you to check the MD5SUM on the update file and giving you a value to compare it to. I did that this morning and found most of my gateways had a different MD5SUM. In this situation you are asked just to follow the SK and delete the update files forcing it to redownload the update file. What I "think" happened was that during the outage CP released update file 110424_1 however there was a problem or it did not fix the issue so they tweaked the file in real time without changing the version number. problem was any gateway that had already polled in and downloaded the not working version of 110424_1 would not redownload it as the version had not changed but any gateway checking in after would work fine. This is why the same update file has different MD5SUM. I suspect like me you checked the version before following the SK to force an update and thought "I have the updated file already" even though what we had was a broken version and we needed to download the working one. So yes do an MD5SUM as per the SK I suspect you will get an MD5 of 3c7770bbd52b039c8d2e1f59dc6f32a6 in which case you have the wrong file so go ahead and follow the SK to force it to redownload the same version number.

[TP_Master · Accepted solution]

Hi, let me introduce some more information.

As I wrote last week even after releasing the package we encountered cases of customers still seeing the issue. We later saw evidence on incorrect MD5 and that's why we added that section to the SK182202.

We did not tweak the signatures in the package therefore no new package was issued but we did perform manual operations to speed up the integration & deployment of package 110424_1 into the updates system, so that our customers get it faster than usual - this caused some issues with wrong MD5 for small portion of customers.

Therefore the recommendation is for anyone who still has issues with X-VPN classification to check the MD5 and if necessary force re-download of the package.

Ofir Israel

VP, Threat Prevention

Check Point 

[Yuber_Sierra_av]

I keep presenting the same error on several pages without a positive response yet,

[Bob_Zimmerman]

I have the 3c7770bbd52b039c8d2e1f59dc6f32a6 hash on one of my VSs, and following the process in sk182202 does not change it. Spent a while on the phone with diamond, and we haven't yet been able to get it to match the hash from the SK. It's very weird how inconsistent this seems to be.