R81.20 feedback

[the_rock]

Hey guys,

Figured would share my feedback so far on brand new distributed install of R81.20 in esxi lab. I really do like zero phishing feature, though for that to work, https inspection has to be on, so may try that out some time this week.

In all honesty, I dont see any drastic changes from R81.10 as far as policy layout, log filtering, IPS...

Also, not sure if this is just my lab, but I made few rule changes and for some reason, accelerated policy push never takes an effect, though its not disabled.

Just my 100% honest feedback, looks good so far, but the real test would be to see it in busy production environment.

Anyway, thats all I can think of for now. Will add more things as I do more testing : - )

[JozkoMrkvicka]

<irony joke>

Check Point - Security vendor where new version brings more bugs ! Please invest with us and you will get much more fun and troubles. 

PS: Best advice ever - If we have no clue about your problem, you have to update Jumbo Take to the latest one so we have plenty of time to postpone resolution of your problem !

</irony joke>

[_Val_]

Is this based on a particular R81.20 experience, or are you just venting? Tags or not, this comment is not helping anyone, in my opinion.

[nmelay]

Wow. I jumped from Firewall-1 3.0b to NG AI R55 almost 20 years ago, and that already seemed like a giant leap.
I don't think many people here realize how old this stuff is.
By 2017, they were using security software from 1997. Just wow.

[the_rock]

R55 is oldest I remember. Im sure I was still a teenager during Firewall-1 3.0b code...yup, googled when it came out and I was 19 back then 😊

[PhoneBoy]

The first version I worked with was FireWall-1 2.0...back in 1996. 🙂

[the_rock]

1996, what a year...I think that was the year I first played chess on the computer in this s***ty yellow-ish color haha. But, back in eastern Europe where we lived, we were happy if someone gave us CD to listen to LOL

[nmelay]

And your own website and FAQ instantly became a reference for everyone working with Check Point firewalls! 👍

[Ilya_Yusupov]

hi @Pedro,

i will be happy if you can share the case with me and i will try to assist.

Thanks,

Ilya 

[Pedro_Madeira]

Hi Ilya,

Thanks for the help. I will tell you the SR number in a direct message.

PM

[Ilya_Yusupov]

Hi @Pedro_Madeira ,

i got it, will review and back to you on Sunday.

Thanks,

Ilya 

[the_rock]

@Pedro_Madeira , you are in good hands man, @Ilya_Yusupov helped me and my colleague with ISP redundancy weird issue, he is EXCELLENT!!

[Pedro_Madeira]

Yeps,

I'm already interacting with Ilya which is great.

Thanks the_rock

[the_rock]

Im sure it will be solved with @Ilya_Yusupov involved.

[Ilya_Yusupov]

@Pedro_Madeira,

i answered also privately but also wanted to share the thread, based on the latest files you shared with me, we see an issue with MAB portal, we saw high amount of processes ~2k related to MAB portal.

we have a solution written in sk173663, please follow the instructions there and update if it's resolved the issue,

Thanks,

Ilya  

[Pedro_Madeira]

Hello,

In response to @Ilya_Yusupov and to give everyone more context, Ilya suggested following sk173663 which is an internal SK. Basically due to the re-design of VPN RA and MAB, an issue cropped up related to the unlimited spawning of processes which consumes memory as they keep cropping up.

When I saw Ilya's instructions, I remembered that I applied this same solution to another customer more than a year ago, as suggested by TAC, so this problem is still lingering in R81.10 and probably in R81.20.

I applied the solution to the current case I'm handling and now we'll monitor the cluster state and memory increase to determine if the problem is solved.

Thank you to Ilya for the extra mile in helping me solving this case.

Pedro Madeira

[the_rock]

@Ilya_Yusupov is awesome, he was super responsive to my colleague and I for weird ISPR issue, I had never seen someone so dedicated to solving an issue. Fantastic human being.

[genisis__]

Ilya is a great TAC engineer!

[the_rock]

Well, he is a group manager, but as I always say, titles mean absolutely nothing, what matters is a person themselves and he is truly one of a kind, in a best way possible.

[Ilya_Yusupov]

Hi,

first of all i'm happy to assist so feel free to contact me whenever you need an assistance :).

Second i'm a QA group manager responsible for FW, SSLi, VPN, IDA and all CP infra, coreXL, SXL and streaming path.

last @Pedro_Madeira  - i will take it with RnD owners to check how fast we can solve this issue and making the SK to be public for meanwhile.

Thanks,

Ilya 

[the_rock]

Something else I wanted to share...I never had this issue in R81.10 with https inspection. So say you want to allow specific website, but I noticed that even if category is allowed, it may give you cert warning and complain about HSTS. Now, even if you disable HSTS for that site in specific browser, it still may not work consistently.

Just something to be aware of, so you dont get surprised if you use inspection with R81.20.

[abihsot__]

I noticed that SNMP for processor IDLE time no longer returns correct data.

sk90860

.1.3.6.1.4.1.2620.1.6.7.2.3

[the_rock]

Hey @abihsot__ ,

Let me test that tomorrow and report back.

Andy

[the_rock]

@abihsot__ Can you please provide exact command you ran?

[the_rock]

Not really snmp guru at all, but below is what I have:

[Expert@quantum-firewall:0]# snmpwalk -v 2c -c public localhost .1.3.6.1.4.1.2620.1.6.7.2.3
SNMPv2-SMI::enterprises.2620.1.6.7.2.3.0 = Gauge32: 6
[Expert@quantum-firewall:0]#

[abihsot__]

oh, yes, sorry, I should have provided the full command to replicate the issue, but you got it right.

So essentially unless your gateway is very busy, you should not get "6". Try the same command with any other gateway (R80.40, R81.10) and it should give you back accurate result.

Anyway, registered TAC case, because for me it looks like a bug, unless IDLE time was moved intentionally to another SNMP OID

[the_rock]

K, gotcha...never really paid attention to it, but keep us posted what they say. I see what you mean...below is for R81.10

[Expert@cp-firewall:0]# snmpwalk -v 2c -c public localhost .1.3.6.1.4.1.2620.1.6.7.2.3
SNMPv2-SMI::enterprises.2620.1.6.7.2.3.0 = Gauge32: 72
[Expert@cp-firewall:0]#

[Naama_Specktor]

Hi @abihsot__ ,

Mt name is Naama Specktor and Ia mcheckpoint employee ,

I will appreciate it if you will send me the TAC SR # , here or in PM.

Thanks!

Naama 

[the_rock]

Just to further update you, this could be inconsistent, because I got totally different output after I tested this 4 hours later...

Andy

login as: admin
Pre-authentication banner message from server:
| This system is for authorized use only.
End of banner message from server
admin@172.16.10.205's password:
Last login: Wed Jan 18 16:17:42 2023 from 172.16.10.103
[Expert@quantum-firewall:0]# snmpwalk -v 2c -c public localhost .1.3.6.1.4.1.2620.1.6.7.2.3
SNMPv2-SMI::enterprises.2620.1.6.7.2.3.0 = Gauge32: 95
[Expert@quantum-firewall:0]# fw ver -k
This is Check Point's software version R81.20 - Build 703
kernel: R81.20 - Build 597
[Expert@quantum-firewall:0]#

[abihsot__]

This is how it looks if you plot it on the graph after the upgrade to R81.20. While testing with snmpwalk you might got into peaks.

So the sum of below three items should be 100, which is no longer the case in R81.20.

[the_rock]

I assume you got that graph from SV monitor, but either way, I can see lots of things fluctuating in my lab as well and I only have single windows behind it, so definitely makes no sense. Never used to happen in R81 and R81.10.