- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Hi Checkmates,
One of the greatest thing with Check Point products is that you can deeply adapt and customize configuration to fit your needs.
Once, someone from Check Point told me "Check Point, it is a car with manual gear, you really decide how the gateway behaves". Ok why not, but let's stop here this automotive metaphore.
One thing to adapt is kernel global parameters. Every Check Point engineer reguarly have to set specific value for specific architectures, specific constraints, ...
See SK26202 to know how to set kernel global parameters.
I would like to start a discussion to gather recommandations about kernel parameters
The purpose is not to document here all possible parameters and values, but the most useful, based on your experience.
So, I start with 2 useful settings that I often configure in my cluster deployments :
Based on your inputs, maybe we might then create a configuration script to automate some kernel settings. Open discussion.
Regards,
Benoit
It's very hard to give "general" recommendations. We have 30+ firewalls in the network and we treat fwkern tweaking carefully as you may create problems if you set wrong parameter on wrong firewall - i.e. whether it's normal or VSX gateway, or chassis or management, what release it is running etc. You would need to keep separate tables depending on those inputs to start with and that might get messy.
But I would certainly recommend to keep your "own set" for your network.
One that could be fairly generic and we prefer it, is to monitor all VLANs in ClusterXL
fwha_monitor_all_vlan=1
Monitors all VLANs in ClusterXL - both in VSX mode and in Gateway mode. Used to discover issues with VLAN configurations or to make sure all VLANs are working properly
Hi Kaspars,
Thank you for your input.
I completly agree : there isn't a single set of settings that could fit for all and such tweaking must be handle with care.
Regards,
Benoit
There are a couple of useful kernel variables mentioned here:
Note that you can also dump every possible kernel variable (both for INSPECT and SecureXL/sim) as described here:
sk33156: Creating a file with all the kernel parameters and their values
Did this while performing research for my book and found all kinds of interesting undocumented variables...tweak them at your own risk though...
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
prior to R77.30, the most important parameter in fwkern.conf was "MAC magic" and "forward MAC magic".
Some additional parameters related to CUL mechanism and policy installation timeouts.
I would like to add that fwha_forw_packet_to_not_active parameter is also connected with solution for many possible issues:
Simultaneously pinging the cluster members and the VIP address...
"Contract entitlement check failed" error on policy installation failure
Cluster debug shows "FW-1: fwha_forw_ssl_handler: Rejecting ssl packets to a non-active member"
"ERR_CONNECTION_REFUSED" error is displayed in web browser when connecting to Gaia Portal
Cluster debug shows "FW-1: fwha_forw_ssl_handler: Rejecting ssl packets to a non-active member"
So, in my opinion, enabling this could be considered a "best practice" even.
Don't forget the MSS clamping parameters, specially when a VPN is in the picture you can solve a lot of problems, including performance, by adding MSS Clamping.
New VPN features in VPN in R77.20 and later
This also requires some changes to another file simkern.conf. when applied to a VPN
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY