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. 

[SimonAmann]

Hi all,

we're also affected. 

Is there any statement from CheckPoint yet?

[dheidler]

Hi,

we also face this issue starting at around 03:40 AM (german time).

[Pedro_Madeira]

I just had a customer this morning with the same problem. 

we had to allow anonymizers in order to make traffic work properly.

HTTPS outbound for many sites was being categorized as Anonymizer with application name X-VPN. Customer is using full HTTPS Inspection as well.

[StackCap43382]

For one customer the involvement of a 3rd Party Web proxy triggers this issue. 

Bypassed the issue is resolved. 

As other have done we have added an explicit ALLOW for the application while TAC investigate. 

[Fr4nky]

I had the same problem with an hospital.

Please fix ASAP and give feedback .

[Jan_Kleinhans]

Information about this problem is a little bit rare.

On support.checkpoint.com it says " 10:30GMT-We are aware of the X-VPN miscategorization in Application Control/URL Filtering blades. Working on mitigating it (will update every 30 min)." 

At 11:00 GMT The info is the same:

11:00GMT-We are aware of the X-VPN miscategorization in Application Control/URL Filtering blades. Working on mitigating it (will update every 30 min).

Where to find these updates? Why there is no offical information via product alert?

Regards,

Jan

[_Val_]

@Jan_Kleinhans I understand the frustration, but you just mentioned an official banner on support.checkpoint.com. 

[Alex-]

We had to authorise Anonymizer and Critical risk otherwise general traffic would still be blocked as X-VPN.

[K_R_V]

Problems seems to be resolved with the new update : DB version: 11042401

It's surprising how Check Point hasn't issued an official statement to customers and partners yet regarding this outage.

[hammerli]

Same problem here after Application Control database auto update to version 24041001 (7042401). Apparently solved after manual updating to 24041101 (11042401).

[Alex-]

Updated manually to 240411110055 and looks OK since.

[TP_Master · Accepted solution]

Hi,

I can confirm that indeed from the last ~15 minutes this issue has been resolved, using the APPI package 11042401. 

Gateways will be updating according to their scheduled update policy. 

If you need to rush the update, please do the following on the security gateways:

- # rm $FWDIR/appi/update/Version
- # rm $FWDIR/appi/update/next_update
- Wait for 5 minutes.

A new dedicated sk182202 is now available for this issue.

An official and detailed RCA will follow.

Ofir Israel 

VP, Threat Prevention Check Point Software Technologies

P.S. We are aware that the fix seems to have not worked for a limited amount of our customers. We currently suspect this as a logging behavior where old connections have new sessions and are updated on the log view. If you encounter drops please let us know through a TAC ticket, we are monitoring the situation. 

[Moti]

Thanks Ofir !

[Nenad_Odic]

it works now thanks

[LeontevAM]

Thanks 

[Expert@:0]# more Version
:appi_version ("110424_1")

[Christopher_Bar]

Mate this is a stellar failure on Checkpoints part. It clearly shows that there is no testing or woefully inadequate testing of URL+Category updates prior to releasing them, which If im honest is quite scary.

How am I supposed to have any trust or confidence in Checkpoint's automatic updates now that I know any junk can be pushed to my gateways.

[Jennifer_Wilson]

Hi,

Gateways have the updated App DB, but logs in SMS server still showing lots of random rejects with apps identified as X-VPN.
BUT have not had any complaints from users, and have not seen anything rejected in my browser despite the logs showing several rejects for me today. It's almost like the logs are showing rejects that aren't happening.

Is there any web url that shows as always being rejected from this that I can test with?

[Mike-H]

I've just had it trigger on https://www.think-cell.com/en

[Fiqri_kurniawan]

Hello Ofir, Hello everyone.

I was very happy when this issue was immediately resolved for your environment.

Currently my MD5 still has the MD5 issue "3c7770bbd52b039c8d2e1f59dc6f32a6" even though it has been updated again.

I think I have to try force updating as above. But from your experience, when we "rm" and wait 5 minutes, does the user's connection to a website become disconnect until the file is created?

Thanks.

[_Val_]

No, the update should not be intrusive

[Fiqri_kurniawan]

Hello Val, Thanks for your explaination.

Anyway, are we need checkpoint gateway connect to website checkpoint like updates.checkpoint.com during do :

- # rm $FWDIR/appi/update/Version
- # rm $FWDIR/appi/update/next_update
- Wait for 5 minutes.

thanks

[_Val_]

Please look into sk143972, already mentioned in this discussion, for full details concerning the manual forced update of the categorization DB.

That said, it is no longer required for the subject of this discussion, the issue was fixed a long time ago.

[_Val_]

All,

We released a new categorization package appi 24041101 which fixes the issue. The gateways will update automatically according to their schedule.

If you need to rush the update, please use the procedure from sk143972.

We are also working on a dedicated SK for this issue, I will share it when ready

[Thomas_Eichelbu]

Hello Val, 

are  those update sent to all countries at the same time?
i see i have new updates on all my international sites.
but it only works for me in Austrian and German locations.
For example in Brasil and Vietnam i still see matches on X-VPN.

i know Check Point doesnt sent out Scan Engine updates to all continent at once for example.
does this also apply to APPL + URL Signatures?

take a look:

different countries different version, only the end 2401 is the same ...

[Pachango]

Unfortunately there are multiple sites on 110424_1 & where sk182202 was followed but the traffic is still recognized as X-VPN... Any extra tips?

[bstorey]

We are also still having issues. We have followed the instructions in sk182202 and have confirmed that all gateways are now running at the latest version of application control. 

It has made some minor changes such as redirecting some traffic but overall, traffic is still being categorised as X-VPN and being blocked. 

[Albin]

Could be some cache. Try reboot on standby member to clear caches. & failover. 

[Sajgon107]

The same problem in one our customer, any ideas please?

[Double]

This issue is continuing to affect us on multiple gateways, with unrelated traffic being misidentified as X-VPN application connections, despite all gateways having downloaded and installed the latest patched package version (110424_1) as outlined in the related support document (https://support.checkpoint.com/results/sk/sk182202)

[796570686578 · Accepted solution]

I noticed something that may help others as well.

Yesterday once the issue has been resolved and the new package released, I performed the Update of the Application Control & URL Filtering via SmartConsole. This resolved the issue on 2 out of 3 clusters. The 3rd cluster, although it had the same updated package version(110424_1) as the other gateways, was still dropping traffic.

So I performed the steps mentioned in https://support.checkpoint.com/results/sk/sk182202 and suddenly it worked. The package version was still the same but apparently there was a difference between updating via Mgmt and manually deleting the files.

Hope this helps anyone else