topic First impressions R80.30 on gateway - one step forward one (or two back) in General Topics

First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Sat, 18 Jan 2020 11:12:09 GMT

Ok, we were finally "forced" to go ahead and upgrade our gateways from R80.10 to R80.30 for fairly small things - we wanted to be ale to use O365 Updatable Object (instead of home grown scripts) and improve Domain (FQDN) object performance issues when all FWK cores were making DNS queries causing a lot of alerts (see https://community.checkpoint.com/t5/General-Topics/Domain-objects-in-R80-10-spamming-DNS/m-p/19786)

Positive things - upgrades were smooth and painless - both on regular gateways and VSX.

All regular gateways seems to be performing as before, but I have to be honest that they are "over-dimensioned" and having rather powerfull HW for the job - 5900 with 16 cores.

VSX though threw couple of surprises.

SXL medium path usage. CPU jumped from <30% to above 50% on the busiest VS that only has FW and IA blades enabled. Ok, there is also VPN but only one connection:

I haven't spent enough time digging into it but for some reason 1/3 of all connections took medium path whereas before in R80.10 it was nearly all fully accelerated. And most of it was HTTPS (95%) with next most used LDAP-SSL (2%)

I used the SXL fast accelerator feature (thanks @HeikoAnkenbrand https://community.checkpoint.com/t5/General-Topics/R80-x-Performance-Tuning-Tip-SecureXL-Fast-Accelerator-fw-ctl/td-p/67604) to exclude our proxies and some other nets and you can see that on friday CPU load was reduced by 10% but nowhere near what it used to be.

I just find it impossible to explain why would gateway with only FW blade enabled start to to throw all (by the looks of it) traffic via PXL. And statistics are a bit funny too:

FQDN alerts in logs. I can definitely confirm that only one core now is doing DNS lookups (against all DNS server you have defined, in our case 2). But we are still getting a lot of alerts like these: Firewall - Domain resolving error. Check DNS configuration on the gateway (0)

Especially after I enabled updatable object for O365 in the rulebase.

As said before - I have not spent too much time on this as we had other "fun" stuff to deal with on our chassis, so it's fairly "raw". I will report more once I had some answers

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Sat, 18 Jan 2020 12:10:54 GMT

Just had a closer look at the IPs that are being sent to medium path and all points to O365 / MS.

Strange as O365 object is fully removed now from rules and DB.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Sat, 18 Jan 2020 15:21:35 GMT

Ouch! Penny just dropped, not even sure how I overlooked the fact that CPUSE upgrade changed our hyper-threading from OFF to ON but (!) kept original manual affinity settings. So not surprising that CPU usage was screwed. I.e. our multiqueue was running on 6 "half" cores instead of 6 "full"! etc etc

Something to watch out for if you are using manual affinities on VSX!

Re: First impressions R80.30 on gateway - one step forward one (or two back)

HeikoAnkenbrand — Sat, 18 Jan 2020 16:29:22 GMT

Hi @Kaspars_Zibarts

The Fast Acceleration (picture 1 green) feature lets you define trusted connections to allow bypassing deep packet inspection on R80.20 JHF103 and above gateways. This feature significantly improves throughput for these trusted high volume connections and reduces CPU consumption.

During my tests, I could reduce CPU (Core) usage about 10%-30%. It is also logically, no more content inspection is executed.

I like that you showed that graphically.👍

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Timothy_Hall — Sat, 18 Jan 2020 17:06:44 GMT

Hi Kaspars,

Thanks for your report, a few comments:

1) What do you have set in the Track field of your rules? If using Detailed or Extended logging this can pull traffic into PSLXL to provide the extra detail being requested. Found out about this one while writing the third edition of my book.

2) Do you have any services with Protocol Signature enabled in the Network/Firewall policy if using ordered layers, or in the top level of rules if using inline? This can also cause some of what you are seeing and you should try to stick to simple services (just a port number) in those layers if possible, then call for Protocol Signatures and applications/URLs/content in subsequent layers.

3) As far as that wacky Accelerated Conns percentage, you must have very large amount of stateless traffic, see sk109467: 'Accelerated conns' value is higher than 'Accelerated pkts' in the output of 'fwaccel stats -s'.

4) As you noticed the gateway is much more dependent on speedy DNS starting in R80.20 due to Updatable objects, rad, wsdnsd and a lot of other daemons.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Sun, 19 Jan 2020 17:12:05 GMT

I got a "tip off" from inside CP! Verifying if I'm allowed to publish it here but seems like my PXL issue is resolved! Yeehaa! Power of community! Thanks to @Ilya_Yusupov

And the "secret stuff" here:

Regarding medium path – you see most traffic in medium path due to a known bug we have since R80.20, TLS parser is enabled when the following combinations of blades are enabled

FW + IDA or/and Monitoring or/and VPN (exactly our case!)

You can validate me by running the following command - “fw ctl get int tls_parser_enable” it will bring 1
As WA you can disable it by running the following on the fly - “fw ctl set int tls_parser_enable 0” è for permanent disabled put it under $FWDIR/boot/modules/fwkern.conf tls_parser_enable=0 and reboot.
The above will bring the traffic to be fully accelerated as in previous version.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Timothy_Hall — Sun, 19 Jan 2020 17:51:30 GMT

Wow nice one Kaspars, don't think I would have ever figured that one out. Will disabling the TLS parser as shown cause issues with other blades should they get enabled later?

Re: First impressions R80.30 on gateway - one step forward one (or two back)

rob123 — Sun, 19 Jan 2020 19:56:27 GMT

👍

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Mon, 20 Jan 2020 08:49:11 GMT

@Timothy_Hall as far as I understood R&D are working on proper long term solution to fix it.

As for FQDN alerts, now I can confirm that O365 updatable object is definitely causing it but only on our busy VSX. I haven't seen the same issue on regular gateways.

According to CP, alert is issued when resolver cannot get response to checkpoint.com query. I took a tcpdump and confirmed that DNS is actually responding but it does generate wsdnsd log, here's example of packet capture and matching wsdnsd.elg entry:

[wsdnsd 32546]@vsx1-ext[20 Jan 9:10:33] Warning:cp_timed_blocker_handler: A handler [0xf6f213d0] blocked for 44 seconds.
[wsdnsd 32546]@vsx1-ext[20 Jan 9:10:33] Warning:cp_timed_blocker_handler: Handler info: Library [/opt/CPshrd-R80.30/lib/libResolver.so], Function offset [0x2b3d0].
[wsdnsd 32546]@vsx1-ext[20 Jan 9:10:33] Warning:cp_timed_blocker_handler: Handler info: Nearest symbol name [_Z10Sock_InputiPv], offset [0x2b3d0].

Still digging through my packet capture to see if i can find any strange names / responses etc

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Ilya_Yusupov — Mon, 20 Jan 2020 13:27:46 GMT

@Timothy_Hall - Indeed when you will enabled blades that will require tls parser you will need to remove the WA i suggested.

The WA is currently only for the combinations i sent.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Timothy_Hall — Mon, 20 Jan 2020 20:03:04 GMT

That makes sense, thanks. Will add this workaround to the upcoming R80.40 addendum but be careful to add caveats for which blades are enabled.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Wed, 22 Jan 2020 10:57:47 GMT

Just a quick update on FQDN object alerts.

All was caused by missing rule that would permit DNS requests using TCP from gateway. I have added full details at the corresponding thread about FQDN here:

https://community.checkpoint.com/t5/General-Management-Topics/Domain-Objects-FQDN-An-Unofficial-ATRG/m-p/72958#M10845

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Khalid_Aftas — Sun, 14 Jun 2020 14:01:56 GMT

we upgraded to 80.30 with latest HF, and even with disabling the parser (we dont use other blade) 49% of trafic is going trough medium path, how can we check further ?

Case atm.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Timothy_Hall — Sun, 14 Jun 2020 14:28:40 GMT

Output of enabled_blades please.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Khalid_Aftas — Sun, 14 Jun 2020 16:33:53 GMT

FW,Identity Awerness, IPS.

Got info from TAC (canada) that tcp/445 and https will use medium path on 80.30 regardless of PSL parser disabled or not.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Kaspars_Zibarts — Mon, 15 Jun 2020 08:20:39 GMT

That's correct - file shares (445) is forced via PXL. There's a procedure available to exclude it but it's fairly complex from memory

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Khalid_Aftas — Mon, 15 Jun 2020 08:32:31 GMT

well we used fast_accel to bypass the big flows we had and PXL % droped to 20% now.

That traffic is now overloading SND core .... and fwk are still quiet high....

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Timothy_Hall — Wed, 26 Aug 2020 15:04:51 GMT

Note that the long-term fix for the TLS parser being inappropriately invoked with certain blade combinations has been fixed in R80.40 Jumbo HFA Take 78+. This fix is also going to be backported into R80.20 and R80.30 Jumbo HFAs as well as mentioned in my R80.40 addendum for Max Power 2020. It is always preferable to have this fix present if possible rather than manually tampering with the TLS parser, as doing so can cause further problems.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Khalid_Aftas — Wed, 14 Oct 2020 09:28:29 GMT

More than 4 months laters, multiple sessions with TAC, and still no solutions yet (one special hotfix that did not help), this seems to be a known issue and TAC is not able to sync with r&d to get a fix ? wondering if someone in the community was able to get a fix at the end.

Re: First impressions R80.30 on gateway - one step forward one (or two back)

Ilya_Yusupov — Wed, 14 Oct 2020 09:32:23 GMT

Hi @Khalid_Aftas ,

the fix exist in R80.30 JHF take 219 and in R80.20 JHF 141.

Thanks,

Ilya