GW causes high CPU on all cores

[ChungNguyen]

Hi everyone, I have noticed that uploading some kind of files from the inside network and  VPN to the local network using share file smb causes cpu appliance to reach 50 ~ 60% during the file transfer.

I can try disable IPS, AV, AntiBot but it doen't work

Thank for help

[_Val_]

What kind of VPN? Remote Access, Site to Site? IPSec, SSL?

[ChungNguyen]

I use VPN Remote Access, IPsec and SSL, 

[Chris_Atkinson]

Which appliance model and software version?

[ChungNguyen]

I use Check Point Appliance 5600 and software servison R80.30 hotfix 241, 

[_Val_]

Just for your information. 

We usually refer SMB to Spark gateways, not Enterprise GWs as in your case. As a result, the post was classified to the wrong category. I have changed the title and moved it to the correct space now.

[Chris_Atkinson]

If your clients are using Visitor mode R80.40 JHF and above has some enhancements in this regard, refer: sk168297 

[the_rock]

If you run top, free -m, ps -auxw commands...does it show any specific process consuming high CPU when performing those operations?

Andy

[ChungNguyen]

I try cli top but i see fwk1_dev_0 high CPU, 

[Chris_Atkinson]

Which encryption algorithms are used, are you using those that are AES-NI friendly?

Please refer: sk98950 - Slow traffic speed (high latency) when transferring files over VPN tunnel with 3DES encryp...

[ChungNguyen]

I'm sory, I not sure if it's this?

[the_rock]

I literally had 1 customer ask me if they should change those in 15 years...no one ever touches them, if ever...

You may want to consider upgrade to R80.40 based on below article:

https://community.checkpoint.com/t5/General-Topics/R80-x-Performance-Tuning-Tip-User-Mode-Firewall-v...

[ChungNguyen]

Thank for support, 

I will consider it.

[the_rock]

No worries. If you dont wish to upgrade, thats fine, but please read that link...its super helpful and I believe it would benefit you in this situation by running those commands.

Andy

[Chris_Atkinson]

With respect I disagree, 3DES / DES should be avoided for security and performance reasons.

Further to the SK posted above, refer also: sk73980 - Relative speeds of algorithms for IPSec and SSL

[the_rock]

For security yes, but as far as performance, I had never experienced it myself or with any customers, ever. Just my own experience. Besides, that screenshot @ChungNguyen posted is for supported enc methods in global properties, does not necessarily mean he is using des or 3des in the vpn community at all. But I do agree with you, I would certainly avoid des/3des. for sure.

[Paul_Hagyard]

Perhaps it would make sense for the product to ship with more appropriate modern defaults? The current default settings have probably been the same for the whole time VPN RAS has been available on Check Point. That said, if you are working on an environment upgraded over many years the old defaults hang around.

The whole support algorithm / use algorithm has always been unclear to me also.

It would be nice if phase 1 supported better than DH group 14 - although I'm not sure how significant this actually is from a security perspective.

[the_rock]

I think it all really comes down to this argument...security vs performance.

[PhoneBoy]

We actually support DH Group 15, 16, 17, 18, and 24 through a manual procedure involving GUIdbedit:
https://support.checkpoint.com/results/sk/sk27054

[Paul_Hagyard]

That article says:
"This article applies to Site-to-Site VPN only. This article does not apply to Remote Access VPN)."

There are far too many important settings required via legacy SmartDashboard, guidbedit, and gateway-level commands (or files).

[the_rock]

There is a setting under global properties -> remote access -> vpn authentication -> enc algorithms -> edit, thats for remote access, but even to get new values there, Im fairly sure what @PhoneBoy gave would still apply. I may try it in my R81.20 lab.

[PhoneBoy]

Missed that you needed this for Remote Access.
I suspect that will require an RFE and should be discussed with your local Check Point office.

While I can't say we will ever completely get rid of the legacy SmartDashboard, we are working to reduce the need for it.
We are planing numerous changes to VSX, VPN, and Clustering (ElasticXL) as well as Gaia OS as part of the next major release (R82).
These changes include adding formal API support to areas that currently don't have it, especially with respect to gateway objects (VSX and regular).
This should also make the web-based SmartConsole a LOT more useful.

[the_rock]

Looking forward to it!

[Timothy_Hall]

Agree with Chris here disable 3DES and DES immediately in favor of AES-128 or AES-256, it will definitely improve performance and may do so drastically if the AES-NI feature set is present on the firewall's processor architecture.

[HeikoAnkenbrand · Accepted solution]

Hi @ChungNguyen   

It is normal for a user mode firewall (before there was only a kernel mode firewall without this process) that the process fwk1_dev_0 has a high CPU load and also over 100%. My guess as to the purpose of the fwk1_dev_0 is that it acts as the liaison between the multiple fwk firewall worker processes (fw instance thread that takes care for the packet processing) and the single fwmod kernel driver instance and the process for high priority cluster thread.

                          max_CoreXL_number          max_CoreXL_number
fwk1_dev_0 =  ∑ fwk0_x                     +          ∑ fwk0_dev_x               + fwk0_kissd       +         fwk0_hp
                          x=0                                          x=0

More read here: R80.x - Performance Tuning Tip – User Mode Firewall vs. Kernel Mode Firewall 

Here is what I would do:

1) Enable AES NI in the BIOS on open server  (It should be enabled on a CP appliances).
     More here: R8x - Performance Tuning Tip - AES-NI, R8x - Performance Tuning Tip - BIOS

2) Use the following VPN encryption algorithms AES-128 or  AES-256. It is directly supported by AES NI from the processor.   
    The SHA256 or SHA 384 settings are not important because they are only used for a short time when negotiating the VPN (vpnd daemon).

3) If you have an elephant flow, it becomes difficult. In this case, I would check that priority queuing is enabled so that the
    remaining connections are distributed more fairly.
    More read here R8x - Performance Tuning Tip - Elephant Flows (Heavy Connections).

4) With R80.30 you should also check whether a 2.6 kernel or a 3.10 kernel is installed. The 3.10 kernel works much more efficiently.

[ChungNguyen]

Hi @HeikoAnkenbrand 

I have worked with 3 TACs but they say my system works without problems, due to current hardware requirements it does not meet the requirements, and now need to upgrade hardware.

But I will try your tip.

Thanks for support

[genisis__]

Is this a large file transfer?  If so, it maybe an elephant flow issue, which generally locks up a core.

[Timothy_Hall]

Once you get your VPN settings tuned up, be aware that SMB/CIFS traffic specifically was forced to go at least Medium Path passive streaming until quite recently, even if no deep inspection blades were enabled (i.e. only Firewall and IPSec blades are enabled).  While this behavior can be overridden with fast_accel, it has finally been fixed in the latest Jumbo HFAs; here is the relevant page from my Gateway Performance Optimization R81.20 Course that details the situations that can still cause traffic to be handled in a slower throughput acceleration path (not accept templating) than expected in R81.20, with the CIFS/SMB item highlighted: