- 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)
As a Check Point Partner we are monitoring the Check Point systems of our customers via SNMPv3 over VPN.
When monitoring standby cluster nodes via VPN this of course leads to a "Clear text packet should be encrypted" error in ClusterXL as the active cluster node already decrypts the SNMP packets and forwards it in clear text to the standby member which expects the packets to be encrypted.
The solution always was sk42733:
[Expert@node1:0]# cat $FWDIR/boot/modules/fwkern.conf fwha_forw_packet_to_not_active=1
[Expert@node2:0]# cat $FWDIR/boot/modules/fwkern.conf fwha_forw_packet_to_not_active=1
Check Point stopped supporting this option in R80.20.
It works in all versions prior to R80.20. The official statement is that it's by design of the product as mentioned in Scenario 1 of sk93204. The interesting point is that initially Check Point Support tried to fix it by providing us with a hotfix which didn't work and only then started to argue about the product design.
This means for all Check Point users out there:
Check Point has addressed this issue in R80.20 Jumbo Hotfix (Take 80).
CP is no longer recommending changing the flag fwha_forw_packet_to_not_active flag, as described in sk93204.
Sent.
Hi Danny
I tried the same fwkern.conf change but didn't work too.
Heard about a work-around to create a no-nat rule to each secure gateway.
Else I installed JHF43 which had a fix to this issue, but I am not sure if this solved SNMP issue you are describing.
Check Point support provided a working hotfix to R80.20 JHF (Take 43). However, it's not working from Take 47 anymore. Waiting for a new hotfix..
This really shouldn't be a hotfix.
I'd expect this to be a part of the JHFAs and version releases as a prerequisite.
Hi @Danny
A small update.
Found the SK related to this issue.
SK147493: Unable to connect to the Standby Cluster member from a non-local subnet via SSH or WebUI
SK93204: ClusterXL: Accessing Standby member through IPSec VPN
When using R80.20 GA Take 47 I had to upgrade these hotfix before getting it to work.
accel_HOTFIX_R80_20_JHF_T47_001_MAIN_GA_FULL.tgz
fw1_wrapper_HOTFIX_R80_20_JHF_T47_001_MAIN_GA_FULL.tgz
I had to use fwkern settings fwha_cluster_hide_active_only=1.
Yesterday I did a CPUSE in-place upgrade to R80.30 T200 Official GA release.
fwkern settings was saved due to upgrade but I cannot access SSH and Web UI over VPN after. Ping work.
Back to same issue again. Opened a new case and linked to the original case.
I will keep you updated if anything new happens 🙂
We've also wanted in past to monitor firewall clusters on internet via VPN, but it doesn't make sense to send it to tunnel when using ssh, snmpv3 and restricted source IP access.
It makes perfect sense to monitor the status of standby cluster members in order to known if they are available in cases of cluster failovers. Check Point provides working solutions also for the latest JHF take. I hope they'll include it with the next JHF take in order to avoid having to install an additional hotfix.
Check Point has addressed this issue in R80.20 Jumbo Hotfix (Take 80).
CP is no longer recommending changing the flag fwha_forw_packet_to_not_active flag, as described in sk93204.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY