SK182202 X-VPN app control logs

[the_rock]

Hey boys and girls,

I hope someone can clarify this for me, because no matter what we try in the lab, nothing seems to fix it, as we want to make sure we get it working in the lab first before we advise the customer what to do. So, I saw a post about this last month, above sk shows it was fixed, but no matter what, you see bunch of app control logs showing as x-vpn.

This is original link Im referring to:

https://community.checkpoint.com/t5/General-Topics/Most-URLs-categorized-as-X-VPN-this-morning/m-p/2...

Now, in our lab, running R81.20 latest jumbo 54, we followed sk182202, even rebooted both mgmt and gateway, no joy. Then, we opened the TAC case, guy suggested we clear urlf cache as per sk64280, did that as well, even rebooted again and no matter what, it always show date April 11th 6.55 am for urlf update.

Any idea how to fix this so it shows correct date? Funny thing is that if you try update it manually, shows green and update does happen every 24 hours.

Bug maybe?

Best,

Andy

 

 

[the_rock]

Forgot to mention, I even disabled app control and urlf blades, re-enabled, tested, same issue.

[PhoneBoy]

The update number doesn't necessarily have a date in it.
Here's mine...and I clearly need to update my signatures on my lab machine LOL:

[the_rock]

haha, lol, ya : - )

Anyway, what does smart console show? I remember in the past, it would always show the correct date, thats why its odd that literally every customer I checked (and I confirmed for 4 of them), they ALL show April 11th, 6:55 am

Andy

[PhoneBoy]

To be fair, my R81.20 Standalone machine doesn't pass a lot of traffic, I mostly use it to look at SmartConsole and such.
The only reason my update time is different than yours is my timezone. 🙂

[the_rock]

So I guess its normal, for now anyway? 🙂

Andy

[the_rock · Accepted solution]

Just an update...we had remote with TAC and they confirmed with escalations team its a bug date shows April 11th for urlf update, so thats fine, but SK182202 is whats needed to fix the issue, as it showed right md5 hash for the file indicated in the article.

That indeed did correct the problem.

Best,

Andy