This is a live document that may be updated without special notice. We recommend that you register for our weekly updates in order to stay up to date. To register, go to UserCenter > ASSETS / INFO > My Subscriptions.
Important Notes:
If not stated otherwise, all limitations apply to both Security Gateway and VSX Gateway.
All limitations listed as part of R81 and above (sk166717) are relevant unless stated as resolved.
All limitations listed in R80.20 (sk122486) and R80.30 3.10 (sk152652) are relevant unless stated as resolved.
To see if a limitation has been resolved, enter its ID in the filtering field located at the top of the table.
Non-Supported Features
Non-Supported Features - General
General
Gaia OS
Hardware
Licensing
Cluster
Non-Supported Features - Installation / Upgrade
Upgrade
Non-Supported Features - Infrastructure
VSX
Non-Supported Features - Networking
Networking
IPv6
Non-Supported Features - Software Blades
Firewall
VPN
Identity Awareness
DLP
SmartView Monitor
QoS
SmartProvisioning
Known Limitations
Known Limitations - General
General
Gaia OS
Hardware
Management and Policy
Dual Site Deployment
VoIP
Known Limitations - Installation / Upgrade / Licensing
The image auto-clone feature (set smo image auto-clone state on) only supports SGMs that run the same major version. When you add a new SGM to the R80.20SP chassis (add smo security-group), it must have the same version as SMO installed on it.
To install a license with the 'cplic put' command, before you run the Gaia First Time Configuration Wizard, you must run the 'cplic put' command in the Expert mode.
ISP Redundancy is not supported if Dynamic Routing is configured (because the ISP Redundancy feature must create a static default route that overrides the default route created by dynamic routing)
You must disable the SMO Image Cloning in the Security Group before you assign an appliance of a model that is different from models of other appliances already assigned in this Security Group. Run this command in Gaia gClish: set smo image auto-clone off
Output of the "asg_if" command on Maestro Security Group Members does not show the correct interface speed configured on the Maestro Orchestrator. This is only a cosmetic issue.
On SSM440, interfaces eth<X>-Mgmt1 and eth<X>-Mgmt2 will not be used and should not be configured. The management interfaces are eth<X>-Mgmt4 and eth<X>-Mgmt3.
On SSM440, the auto-negotiation for Forward Error Correction (FEC) on 100Gb ports is not supported. FEC is enabled by default. The user can disable it manually in accordance with the settings on the peer side.
All SGMs in an environment must have the same number of CPU cores. Hybrid Systems (61000 Appliances with SGMs that have a different number of CPU cores) are not supported.
Pre-R76SP
-
MBS-5227
Maestro
It is not supported to install both of the following expansion cards in the same Security Appliance connected to a Maestro Hyperscale Orchestrator:
Enabling ICMP / CCP probing on cluster interfaces (setting the value of the kernel parameter fwha_enable_if_probing to 1) is not supported in VSX mode.
You can only connect one DAC / Fiber cable between a Quad Port Card on an Appliance and each Maestro Hyperscale Orchestrator. Connecting two cables between a Quad Port Card on an Appliance and each Maestro Hyperscale Orchestrator is not supported.
If you enabled and configured the ISP Redundancy on a Security Group, then to force an ISP Link State you must run the g_fw isp_link command in the Expert mode. If you run the fw isp_link command on a specific Security Group Member, the command only changes the state of the ISP link on that Security Group Member.
Before importing a snapshot on SGM, you must check if there is enough free disk space. If necessary, delete old snapshots and other unneeded files to free up disk space. SGMs that do not have enough disk space will not create the snapshot in their database, and there will be no error message to indicate this.
If SGMs lose connectivity to the CMM, the 'asg stat' command displays the most recent status of the system. For example, a chassis module that was "UP" before the CMM lost connectivity, continues to have the status "UP". The state of the CMM is changed to "DOWN".
On an Orchestrator that runs the R81.10 version, you can assign appliances of different supported models (see sk162373) to the same Security Group only if these appliances run the R81.10 version.
After you add a new member to a Security Group using the SMO Image Auto-Clone feature, it might stay in the DOWN state (as the 'asg stat -v' command shows).
To resolve: Manually reboot the new Security Group Member.
Maestro Orchestrators and Security Group CIN interfaces are configured in the subnet of 198.51.10<SG_ID>.0. You cannot use this subnet for data and management interfaces. This applies to Maestro Gateways and Orchestrators on all Maestro versions.
"Added FTW configuration on MHOs:" is displayed in the Orchestrator Gaia Portal in the Security Group Summary window, even when the First Time Wizard settings are not configured.
Installing a Hotfix / Jumbo Hotfix Accumulator on all Security Group members at the same time (and not gradually) overrides the configuration of traffic distribution to default: general and L4 Distribution is enabled.
To prevent the Gaia configuration mismatch between Security Group Members, it is not supported to change the user's password on a Security Group in these ways:
In Gaia Portal > User Management > Change My Password
In Gaia gClish with the command "set selfpasswd"
To change the user's password on a Security Group, run one of these commands in Gaia gClish:
set user <UserName> password
set user <UserName>password-hash <Password Hash>
(Applies to Maestro and Chassis R80.20SP and higher.)
Running the 'show hostname' command in Gaia Clish returns the hostname shared by all the SGMs, but not the specific ID for each SGM. The specific ID is displayed as %m.
The arguments of the global commands are processed before the local (native) arguments, and this can cause the local arguments to be ignored. For example, the 'g_ls -l /tmp/' command is processed as 'ls /tmp/' on the local SGM instead of as 'ls -l /tmp/' on all SGMs.
Relocating the local arguments within the command (where applicable) can resolve the problem. For example, run the 'g_ls /tmp/ -l' command instead of the 'g_ls -l /tmp/' command.
Running the 'asg_hard_shutdown' command on an SGM two times, one after the other, causes a reboot and not a shutdown.
It takes one minute for the SGM to shut down after running the 'asg_hard_shutdown' command. During this interval, do not run the 'asg_hard_shutdown' command again.
When you run multiple Gaia gClish 'set ...' commands, one after another, some of these commands can stop running. When this happens, the message "Processing Transaction" shows in the output.
Collecting Gaia Backup and restoring Gaia Backup in Global Clish (gclish) is not supported on a Security Group that contains appliances of different models.
To collect Gaia Backup and restore Gaia Backup, you must use Gaia Clish (clish) on each appliance in the Security Group.
Remote authentication for the Expert mode using RADIUS / TACACS+ servers (the Gaia gClish command 'set expert-authentication-method {<shared-password> | <user-password>}') is not supported.
It is not supported to create a Gaia snapshot on one Maestro Security Appliance and revert that Gaia snapshot on a Maestro Security Appliance in the same Security Group (for example, with the command 'snapshot_recover').
On SSM440, when working with 1G copper transceiver in ethX-Mgmt4, after SSM reboot the interface will show the link as up but traffic will not pass. Refer to sk126612.
The Ethernet ports on the SGMs are not used. Each SGM has two Ethernet ports that are not used by the system and must not be configured. The output of the 'ifconfig' command displays these ports as eth1 and eth2.
Transceivers for the 40000 / 60000 Appliance are not interchangeable with transceivers from other Check Point appliances. Only transceivers provided with the 40000 / 60000 Appliance are certified for this system.
In Dual Chassis deployment, the external synchronization network between the two Chassis (or between Orchestrators on different sites) must not contain Layer 3 routers (because they drop Cluster Control Protocol packets).
In Dual Site deployment, the external synchronization network between the Orchestrators on different sites (or between the two Chassis on different sites) must guarantee a latency of no more than 100ms and a packet loss of no more than 5%.
In Dual Site deployment, no warning is displayed when changing the "type" of the QSFP port in Gaia Clish on Maestro Hyperscale Orchestrators on the local site, while the Maestro Hyperscale Orchestrators on the remote site are down.
At the end of the installation of the R81 image on a Scalable Platform (Chassis / Maestro Security Appliance), a message appears "You may safely reboot your system". You must manually reboot the Chassis / Security Appliance.
In a rare scenario, after upgrading the 40000 / 60000 chassis to R81.10, the output of the "asg diag print 20" command shows that the test "Configuration File" fails with "Database inconsistent".
To resolve: Reboot the problematic SGM with the "reboot -b <SGM ID>" command.
Installation of a Central license with SmartUpdate requires a policy installation on the Security Gateway / VSX Gateway (in the context of the VS0) object in order to propagate the license.
A Maestro Security Appliance that was removed from a Security Group and then added back to the same Security Group might not pull the license from the existing members of the Security Group. As a result, this Security Appliance remains in the DOWN state.
A newly added Security Group Member remains in the DOWN state, if there was a Virtual System with the 'InitialPolicy' in the Security Group before you added that Security Group Member. (The output of the 'cphaprob list' command on the new Security Group Member shows that the Critical Device pull_config reports its state as problem.)
To avoid this issue:
Examine the VSX state and policies on all Virtual Systems in the Security Group (with the vsx stat command)
If there is a Virtual System with the 'InitialPolicy', install the applicable Access Control policy on that Virtual System
To configure VSX Virtual Switches to forward IPv4 multicast traffic or any IPv6 traffic, it is necessary to disable the correction of local connections:
Connect to the command line on the applicable Security Group
Log in to Expert mode
Run this command to disable the correction of local IPv4 connections in the current session: g_fw ctl set int fwha_local_chassis_state_correction 0
Run this command to disable the correction of local IPv6 connections in the current session: g_fw6 ctl set int fwha_local_chassis_state_correction 0
Run this command to disable the correction of all local connections permanently: g_update_conf_file fwkern.conf fwha_local_chassis_state_correction=0
Important Note: If you created Virtual Switches in R80.30SP with the R80.30SP Jumbo Hotfix Accumulator Take 56 or Take 49, you must install a special hotfix before you install the R80.30SP Jumbo Hotfix Accumulator Take 73 or higher. See sk171917.
In rare cases, after you reconfigure a VSX Gateway with the "vsx_util reconfigure" command, static routes or MTU might not be configured on Virtual Systems. To resolve:
Connect with SmartConsole to the Management Server that manages the affected Virtual System and open the Virtual System object.
To resolve an issue with static routes: write down the current static routes in some text editor > remove the static routes > click OK > open the Virtual System object again > add the static routes > click OK.
To resolve an issue with an MTU value: change the current MTU value to the required MTU value > click OK.
A reset of SIC between the chassis in VSX mode and the Management Server (or between the Security Appliances in VSX mode and the Management Server) might cause the non-SMO members to change their state to DOWN.
While the Image Cloning feature is enabled, a Security Group member may reboot more than one time. To resolve: Disable the Image Cloning feature on the SMO member to stop these reboots.
After running the 'vsx_util reconfigure' command on the Management Server, the VLAN interface on a Security Group in VSX mode might come up without an IP address if the VLAN's MTU was set to a value larger than 1500. Refer to sk111513.
No local configuration should be performed on a Security Group or on a Security Group Members while the 'vsx_util reconfigure' command is running on the Management Server.
It is necessary to wait until all Security Group Members and Virtual Systems are up and running (otherwise, the local configuration will not be applied).
If you lower the Connections Table limit of a Virtual System, and one of the SGMs has more or the same number of connections than the limit, the new value is rejected for that SGM. The new Connections Table limit may be accepted by other SGMs.
Notes:
To see the current number of entries in the Connections Table, run this command in the Expert mode: fw tab -t connections -s
To configure the Connections Table limit of a Virtual System: In SmartDashboard, open the Virtual System object - go to the "Capacity Optimization" pane - set the value in the "Limit the maximum concurrent connections" field - click on OK - install the policy.
The Alerts configuration wizard does not allow setting of performance thresholds per Virtual System.You can manually configure thresholds for Virtual Systems using the 'dbset' command from the Expert mode:
In this example, an alert is triggered when any Virtual System packet rate is higher than 30% x 1.8MB (1.8MB is the default packet rate threshold per SGM).
You cannot enable IPv6 before you create and configure a new VSX Gateway. You must first create the new VSX Gateway and then enable and configure IPv6 using Gaia gClish.
The 'drop_monitor' command fails with "Error! Failed to get current VS <ID>" on a Security Group in VSX mode. Solution is planned for future Takes of the R80.30 Jumbo Hotfix Accumulator (sk165312).
If after creating a new Virtual System object, policy installation on a Security Group object fails with "Error code: 0-2000240", wait 2-3 minutes and install the policy again.
A change in the number of CoreXL Firewall instances (in a VSX Virtual System object in SmartConsole) in Dual Chassis VSLS setup requires a downtime, because the Virtual System must be restarted. During this restart, traffic cannot pass through the Virtual System.
To support the configuration of DoS Rate Limiting rules in Gaia gClish with the "fwaccel dos rate add" command, or in the Expert mode with the "g_fwaccel dos rate add" command, you must install a required hotfix on the Security Group. Contact Check Point Support.
By default, CoreXL is disabled on Maestro Security Appliances 5600. To enable and configure CoreXL, refer to the R80.20SP Maestro Performance Tuning Guide (chapter: CoreXL).
To support asymmetric connections, it is necessary to enable the cluster synchronization in the corresponding service's properties (Advanced pane > in the Cluster and synchronization section, select Synchronize connections if Synchronization is enabled on the cluster > install policy).
It is necessary to install policy after changing the mode of a bond interface (for example, from XOR to 802.3AD), so that the bond interface is monitored by the cluster. For 40000 / 60000 Appliances, applies to Dual Chassis.
In VSX mode, after disabling or enabling the Hyper-Threading feature in the cpconfig menu and rebooting, another reboot is required for the system to apply the Multi-Queue configuration.
When IPv6 traffic passes through Security Groups, it is not supported to disable the 'Drop out of state TCP packets' setting in SmartConsole > Global properties > Stateful Inspection.
"Failed to set MTU 9000 on interface magg0. Maximum value allowed is 9710." error when running the Gaia gClish command "set interface magg0 mtu <Value>" for a Management Aggregation (MAGG) interface.
Workaround:
Configure the MTU on any of the data interfaces to a value greater than 1500.
Configure the MTU on the MAGG interface to a required value.
Connections may break when you change the System Distribution Mode using either the 'set distribution configuration' command or the 'set distribution interface' command.
When using SGM400, 40GB Back Plane (BP) connectivity speed is supported for both SSM160 and SSM440. In order to switch to 40GB, the SSM's downlink ports should be set to 'Auto' Speed. Refer to sk118435.
Configuration of RX/TX ringsize is supported only on eth<X>-Mgmt4 and BPEth<X> interfaces (either with the Expert command 'ethtool -g', or the Gaia Clish command 'set interface ...').
If you installed a 40 GbE card or a 100 GbE card on a Check Point appliance you wish to connect to the Maestro Security Orchestrator, and you did not receive this card as part of the Maestro product, make sure this card meets the minimal requirements:
Connect to the command line of the Check Point appliance.
Log in to the Expert mode.
Run this single long command: for NIC in $(ifconfig | grep ethsBP | awk '{print $1}') ; do echo $NIC: ; ethtool -i $NIC | grep firmware ; done
The 'firmware-version' has to be '12.22.1002' or higher.
When VLAN traffic needs to traverse the Security Group in Bridge mode, you must configure all relevant VLAN IDs on the Uplink ports assigned to the Security Group in the Gaia Portal on the Maestro Orchestrator.
Note: Configure these VLAN IDs in the Gaia Portal on the Maestro Orchestrator.
Example Topology: (VLAN Trunk port) ==== (Uplink ports on Maestro Orchestrator that are assigned to a Security Group in Bridge mode).
Interfaces cannot be shared between Security Groups.
Resolved in Jumbo HFA R80.20SP Take 105: Added support for sharing of management interfaces between Security Groups. This applies to management interfaces that are not part of a MAGG interface in 802.3AD (LACP) mode (a Bond Interface on the Management Ports).”
When two Maestro Hyperscale Orchestrators are connected together, and you need to disconnect many cables from one of the Maestro Hyperscale Orchestrators, first disconnect the cable from the dedicated Synchronization port. This prevents the LSP mechanism from disabling all ports on the other Maestro Hyperscale Orchestrator.
When several Downlink ports on an Orchestrator are connected to the same Security Appliance, these Downlink connections work only in the Active/Backup mode for IPv6 traffic (and not in the Load Sharing mode).
When you configure a routemap that includes the 'direct' parameter, it will also advertise the internal communication networks CIN and Sync. On Scalable Platforms and Maestro Security Appliances, you have to filter out manually such internal communication networks.
If you filter the 'protocol direct' on a routemap and do not specify an interface, then it will also advertise the internal communication CIN and Sync networks.
IPv6 02487403 SSM Layer4 Distribution Mode is supported for IPv4 only. The IPv6 traffic will be distributed based on the Source/Destination IP addresses only.
Note: a system can use SSM Layer4 Distribution Mode while IPv4 and IPv6 are inspected by the Security Gateway. Each IP version will use a different mechanism to distribute traffic, as described above.
VPN traffic on a VSX Virtual System that is connected to a VSX Virtual Switch is supported only when the distribution mode configured for the WRP interface is the same as the distribution mode configured for the physical interface on the VSX Virtual Switch.Example of a VSX topology:
It is not supported to configure a Scalable Platform 40000 / 60000 object or a Maestro Security Group object as a VPN Satellite Gateway if other VPN peers communicate through it.
It is not supported to configure Client to Site traffic over the Site-to-Site VPN tunnel with a Scalable Platform 40000 / 60000 or a Maestro Security Group.
When the Threat Extraction blade is enabled, the original attachment file might not be available for download due to a limitation in a Cluster Load Sharing environment. It is recommended to disable this blade in the corresponding Threat Prevention profile.
If a Threat Prevention policy is installed on a Security Group, while a Security Group Member reboots, that Security Group Member may remain in the Down state after it boots.
To resolve: Manually reboot this Security Group Member.
You must enable the SMO Image Cloning before you add new members to a Security Group, if in the Security Gateway object you enabled the Identity Awareness Software Blade and an Identity Source (for example, AD Query or Identity Collector). Note: If you do not enable the SMO Image Cloning, the new Security Group Member reboots several times before it is completely configured.
Security Group members do not synchronize the configuration file $FWDIR/appi/update/appi_parameters.C automatically. For more information, see sk146993 - notes for Scalable Platforms.
It is not supported to configure the IP address of the Security Group as the main URL of the Mobile Access Portal: In SmartConsole > R80.30SP Security Gateway object > Mobile Access > Portal Settings > Main URL.
For monitoring the 60000 / 40000 Scalable Platforms over the SNMP, the only supported OIDs are under iso.org.dod.internet.private.enterprise.checkpoint.products.asg (OID 1.3.6.1.4.1.2620.1.48).
The 'snmpwalk' or 'snmpget' commands on OIDs that have prefixes with 1.3.6.1.4.1.2620.1.44.20 (asgIPv4PerformanceCounters) or 1.3.6.1.4.1.2620.1.44.21 (asgIPv6PerformanceCounters) display values calculated on the Active Chassis only.
The 'snmpwalk' and 'snmpget' commands executed for the IP address of the Security Group on OIDs that have prefixes other than 1.3.6.1.4.1.2620.1.44 or 1.3.6.1.4.1.2620.1.48 return information only for the current SMO Security Group Member. To get the same information from non-SMO Security Group Members, connect to the command line of each non-SMO Security Group Member and run the 'snmpwalk' or 'snmpget' command for the 'localhost'.
This is a live document that may be updated without special notice. We recommend that you register for our weekly updates in order to stay up to date. To register, go to 