User-Space firewall support for R80.30 3.10 and above

[shais]

User-space Firewall (USFW) is a stable and mature infrastructure that allows Check Point Firewall instances to run in user-space mode, It has been used for several years now on VSX.

As such, Check Point decided to gradually move appliances to utilize USFW starting R80.30 3.10

The motivation for the USFW infrastructure development:

• Support a large number of FW instances.
• Quick process recovery upon a failure or a crash.
• Faster development of new features.
• Improve system traceability, reduce troubleshooting time.

FAQ:

Q: Which Security Gateways/Appliances can utilize USFW?
A: For the list of Security Gateways and appliances that support USFW refer to sk167052

Q: My Gateway is running only 4 cores / VM, why is my machine running in USFW?
A: USFW will gradually become the default mode in future releases, new appliance models are designed and shipped configured to use USFW as the default mode.

Q: Most of my traffic is handled through the SecureXL Fast path, will I benefit from USFW?   
A: SecureXL on USFW mode runs in kernel mode, traffic will be accelerated (in kernel) efficiently similar to the Kernel Mode

Q: Is there any reason to switch back to Kernel mode?
A: Check Point is gradually transferring to USFW mode. It is preferred and best practice to keep the security GW in its default mode, yet it will be possible to switch to kernel mode – please see SK167052 for more details.

Q: How do I determine if the Security Gateway runs using USFW?
A: Run “cpprod_util FwIsUSFW”  (1 = USFW)

Q: Does a USFW work the same as it works with VSX? Do the same limitations apply?
A: Although USFW is using a similar infrastructure as used with VSX, the limitations are different. Refer to sk167052 for USFW known limitations.  

For any additional questions, feel free to tag me in your USFW posts.

[HristoGrigorov]

@shais, may you please clarify how is USFW affecting CPU usage ? There were reports that on some appliances enabling USFW causes much higher processor utilization compared to KSFW. 

[HristoGrigorov]

Just to mention that in theory with USFW enabled it should be possible to replace relevant fw modules without OS reboot 🙂

[_Val_]

@HristoGrigorov, what are you trying to say?

[HristoGrigorov]

@_Val_ I mean that it is possible to replace and reload user space binaries without OS reboot. With some downtime of course but still it will be much quicker. It is at least technologically possible. 

[shais]

USFW should not impact the CPU, we've identified few USFW specific cases that cause excessive CPU utilization and they were fixed and integrated to our Jumbo hotfixes.

If we still have such issues, please contact support and allow us to investigate the issue.

As for your input regarding replacement of FW modules without reboot - You are correct that USFW open this possibility for us and we indeed taking this into consideration and validation

[Hug_for_my_Bug]

Hi,

We have a newly installed 6700 firewall cluster which came installed with User mode disabled. We have noticed high CPU spikes causing high CPU and affecting user experience. Does changing from kernel mode to User mode will have any adverse effect for 12 core firewall.  Is there any sk on how to change on a 6700 appliances?

Thanks

[HristoGrigorov]

You must first investigate what is the reason for these CPU spikes. USFW is not really faster than KMFW. In fact it is a bit slower. It has other advantages though, supports large number of CPUs and system does not reboot in case of fwk crash.

[_Val_]

@Hug_for_my_Bug USFW only makes sense, from a performance perspective, with systems having more than 40 cores. Not your case.

[Borut]

Hi @shais 

I noticed, that in R80.30 USFW was supported on open servers, but with R80.40 it's only supported on machines with 40+ cores. Is that an appliance sales push decision or a technical one? Val is also stating, that performance gains are only observable on machines with more than 40 cores.

What about HTTPS inspection? If I understand correctly TLS 1.3 native support (without downgrading to TLS 1.2) is only possible in USFW. Does that mean there will be no realistic possibility to have native TLS 1.3 support on open servers?

Best regards
Borut

[_Val_]

@Borut It always helps to tag people you mention 🙂

I believe, the limitation of support with R80.40 and up comes mostly from QA effort. We can only support what's being tested thoroughly. If you have an actual and important use case, raise it with the local CP office as RFE. 

Concerning the general plans to support TLS 1.3 on open servers with less than 40 cores, I have reached out to R&D. I will let you know when they answer.

[Borut]

Sorry @_Val_  🙂

No use cases yet, since majority of the internet still supports TLS 1.2. Just wondering about the times when that isn't the case anymore. 

Thanks

[_Val_]

@Borut The mentioned SK is now in review and may be changed, as the info there is not 100% accurate. We do plan to make USFW mode default in the upcoming releases, for all platforms.

Once again, if you have a need to run TLS 1.3 on open server today, reach out to the local office and raise a request. Should be relatively easy to handle. If you need any further assistance, feel free to PM me any time.

[Borut]

@_Val_ 

I think no assistance is necessary right now, since it does not brake anything. Thanks for the inquiry and your time.

[_Val_]

No problem, we are here to help

[Paul_Hagyard]

Neither this page, the referenced sk167052, or the R80.40 next gen security gateway documentation provide any guidance on how to enable this... I am guessing setting FwSetUsfwMachine=1?

cpprod_util 2>&1 | grep -i usfw
FwIsUsfwMachine no-parameter integer-output
FwIsUsfwMDTDisabled no-parameter integer-output
FwIsUsfwEpoll no-parameter integer-output
FwIsUSFW no-parameter integer-output
FwSetUsfwMDTDisable integer-parameter no-output
FwSetUsfwEpoll integer-parameter no-output
FwSetUsfwMachine integer-parameter no-output

[Timothy_Hall]

As noted in my book, generally you should not change the default state of USFW unless under the direction of TAC.  The rules about whether USFW will be enabled by default are complicated and were initially revealed in my posting below after a chat with Check Point R&D: 

https://community.checkpoint.com/t5/General-Topics/USFW-on-appliances-with-less-than-40-cores/m-p/86...

The latest updates conerning this are contained in this SK: sk167052: Check Point User-Space firewall support for R80.30 3.10 and higher  Assume that USFW will be enabled by default on all new firewall appliance models going forward.

However if you want to manually toggle the state of USFW, the cpprod_util commands you need to use are mentioned here in an excellent article by @HeikoAnkenbrand:

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

[Paul_Hagyard]

Hi Timothy,

Thanks for the information. The environment in question is a 5800 cluster recently upgraded to R80.40 (latest GA jumbo), one of the devices listed as not defaulting to USFW but able to move to it. PSLXL packets are up around 60%, well above the 30% indicated in sk167052 where USFW is the preferred mode. I'll raise a SR and see what TAC have to say.

The referenced sk149973 in Heiko Ankenbrand's post has now been made Check Point internal-only - although his post still describes how to enable USFW 🙂

Cheers,

Paul