R80.20 Issue : Monitoring standby cluster members via VPN

[Danny]

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:

• You cannot directly login to standby cluster nodes via VPN anymore (SSH, GAiA WebUI)
• You cannot securely monitor the standby cluster nodes via VPN (ICMP, SNMP)
• You need to create workarounds that make troubleshooting times longer and raise complexity

[PhoneBoy]

Can you send me the related SR privately? Let me ask around in R&D.

[Danny]

Sent.

[Kim_Moberg]

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.

[Danny]

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..

[Vladimir]

This really shouldn't be a hotfix.

I'd expect this to be a part of the JHFAs and version releases as a prerequisite.

[Norbert_Bohusch]

I already told my colleagues to open as many SRs as possible for this issue (so for each customer we upgrade to R80.20), so TAC has awareness this should be part of JHF

[PhoneBoy]

There are specific requirements that hotfixes have to meet before they are rolled into a jumbo.
Not knowing anything about the specific hotfixes, I can't comment what the specific issues are in this case.
That said, awareness of a widespread issue is definitely a factor, so open those SRs 🙂

[Kim_Moberg]

Hi Danny
i just solved this with R&D.
Yes fwha_forw_packet_to_not_active=1 will not do any difference.
You need a jhf with both accpck and fw_wrapper.
Last part have been to use kernel command fwha_cluster_hide_ip=1 instead.

But again you need to have 2 hotfixed installed on top of r80.20 take 47 GA

Best regards
Kim

[Kim_Moberg]

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 🙂

[Martin_Valenta]

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.

[Danny]

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.

[Danny · Accepted solution]

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.

[Kim_Moberg]

Hi Danny
Thats the one I have been refering to.
PMTR-33209, PMTR-30582

If you upgrade to R80.30 it is not released in the first version. Wait for the first GA take or ask for JHF that solves this issue.