Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
ProxyOps
Contributor

CP 6700 Cluster Standby Member can't reach internal NTP, DNS and the Internet

Hello,

 

we deployed a new CP 6700 Cluster in HA Mode as have done it  a couple of times without any problem like that.

Now we faced the the exact same issue as the User in this CheckMates Post:

 

https://community.checkpoint.com/t5/Security-Gateways/Virtual-Standby-member-cannot-reach-internal-D...

 

I used the workaround with the fwkern.conf command "fwha_cluster_hide_active_only = 0" to fix the issue for this cluster.

 

I would like to explain to my colleagues why this fwkern.conf command is required for this new cluster. We run many HA Clusters and all of them run R80.40 Take 91 without the need for this fwkern.conf command.

 

Can somebody explain me, why we need this hotfix and how can we change our setup to remove the need the need of this fwkern.conf command. I also would be interested why this problems only occured on this cluster.

Edit: We also noticed hard "laag" with the commands in expert mode: "arp -a" and "tcpdump" the output needed about 1~ Minute to display the results. This issue was also resolved with the fwkern.conf command.

Best regards

 

0 Kudos
4 Replies
PhoneBoy
Admin
Admin

I suspect there is a bug somewhere that accounts for the need for this workaround.
I recommend a TAC case.

0 Kudos
JozkoMrkvicka
Leader
Leader

Do you have DNS configured on standby node?

If you perform failover, the issue is still occuring on only standby member (former active) ?

Can you check NAT rules for any strange NAT rules ?

Kind regards,
Jozko Mrkvicka
0 Kudos
ProxyOps
Contributor

Hi @JozkoMrkvicka ,

 

yes DNS was configured correctly. 

yes the Problem always occurs on the Standby member. (Former Active).

 

We worked with a clean new ruleset without any dirty NAT rules, as this Cluster is still in the Build Phase. 

Best regards.

0 Kudos
Václav_Brožík
Collaborator

Such lags of tcpdump, arp etc. are normally caused by non-responding DNS because these tools translate IP addresses to names by default. In your case Check Point's default cluster hide fold NAT was failing so DNS did not work.

Almost always it is better to use these tools without DNS resolutions for L1-L3 troubleshooting:

* arp -an

* tcpdump -n

* traceroute -n

* ...

Note: I had to troubleshoot and disable the cluster hide fold NAT multiple times. I would love if the default behaviour would be the simple communication of the cluster nodes using their own IP addresses.

0 Kudos