topic Re: ClusterXL - standby cannot reach gateway in Firewall and Security Management

ClusterXL - standby cannot reach gateway

Richard_Scott1 — Mon, 10 Sep 2018 13:21:24 GMT

I've got a R77.30 cluster of two nodes (running on vmware).

The active node can ping the default gateway and onward to the rest of the network without any issue.

However, the standby node can't even ping the gateway, let alone anything beyond it. If I unload the policy from the node, then it is able ping it.

Logs suggest the traffic is being nat'd to the cluster's address. The gateway can ping active, standby and cluster addresses.

I've tried fw ctl set int fwha_forw_packet_to_not_active 1 on both nodes, but that didn't help.

The management interface is reachable via a different gateway (and static route).

Any suggestions greatly appreciated!

Re: ClusterXL - standby cannot reach gateway

PhoneBoy — Mon, 10 Sep 2018 13:44:35 GMT

I'm pretty sure that's the wrong "fix" for the problem, reading this sk: ClusterXL drops traffic with 'dropped by fwha_forw_run Reason: Failed to send to another cluster member'

But perhaps the debugging in this SK might be helpful in figuring out where the true problem is.

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Mon, 10 Sep 2018 13:55:33 GMT

Thanks. I've tried the 'fw zdebug' command both with and without that "fix" (currently disabled).

Only error displayed is :-

;fw_log_drop_ex: Packet proto=-1 ?:0 -> ?:0 dropped by fwha_select_arp_packet Reason: CPHA replies to arp;

Re: ClusterXL - standby cannot reach gateway

PhoneBoy — Mon, 10 Sep 2018 14:40:59 GMT

There's at least one TAC case that mentions this error message and the fix for it being the kernel variable you set it.

Which suggests a TAC case might be in order for further troubleshooting.

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Mon, 10 Sep 2018 14:42:12 GMT

ok - thanks. I'll get a case logged.

Re: ClusterXL - standby cannot reach gateway

Maarten_Sjouw — Mon, 10 Sep 2018 20:46:32 GMT

One of the things with running clusters in VM-Ware is that they run better with VRRP. Then you can also control this behaviour from the Dashboard.

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Tue, 11 Sep 2018 13:50:05 GMT

The decision not to use VRRP was taken by a Checkpoint engineer, not us. They migrated us from an old (R6x) physical cluster to the new R77.30 VMware based one.

Support ticket has been responded to, asking for any error shown by zdebug drop... even though I'd included that in the original ticket.

I'm now waiting for them to set up a remote session..

Re: ClusterXL - standby cannot reach gateway

Maarten_Sjouw — Tue, 11 Sep 2018 14:04:45 GMT

Yeah I know, when you open the ticket, you upload the cpinfo, first thing they ask for is? Yep a cpinfo.

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Tue, 11 Sep 2018 16:30:17 GMT

End of the working day for me here in the UK and no progress. Updated the ticket 8 hours ago with suitable timeslots for remote access, but not heard anything at all..

Re: ClusterXL - standby cannot reach gateway

Maarten_Sjouw — Tue, 11 Sep 2018 18:20:10 GMT

If you have the opportunity, switch to VRRP and see what comes of it.

Be aware that in the VM switch you have to disable all security features of the ports connected to your FW's and make sure IGMP snooping is allowed.

When you do choose VRRP do not use extended vMAC just the standard vMAC mode.

Last resort, try if you need to change from multicast to broadcast for ccc protocol.

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Wed, 12 Sep 2018 11:48:48 GMT

It's a production firewall, so slightly hesitant to switch to VRRP yet..

Had a ticket update overnight, to say someone else is working it and asking me questions I've already answered 🙂

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Thu, 13 Sep 2018 09:14:30 GMT

Not impressed with support at all.

Spent an hour on the phone and clearly explained that the problem affects all outgoing traffic from the standby node (specifically NTP, DNS and HTTPS) but the tech has focused solely on NTP and wants screenshots of the NTP configuration, diagnostics of NTP, etc.

Completely ignoring the basic fault that there's zero outbound connectivity to anything via the default gateway.

Re: ClusterXL - standby cannot reach gateway

G_W_Albrecht — Thu, 13 Sep 2018 10:12:17 GMT

What i would want to know is the current business impact of this issue - are any TP updates not working on the standby node ?

Re: ClusterXL - standby cannot reach gateway

Richard_Scott1 — Thu, 13 Sep 2018 10:16:16 GMT

Immediate impact is that the standby can't get any checkpoint updates, sync time. We're also looking at deploying the IPS blade onto it, but can't while the standby can get out of sync for updates, etc.

Re: ClusterXL - standby cannot reach gateway

G_W_Albrecht — Thu, 13 Sep 2018 10:54:15 GMT

Do you already know sk43807 Anti-Virus / URL Filtering / IPS update fails on the Standby member of ClusterXL in High Availability mode ?

Re: ClusterXL - standby cannot reach gateway

Networks_Winter — Thu, 21 Mar 2019 09:08:03 GMT

Hi,

We have the same issue where the secondary node is not able to reach the next hop gateway. Did you come to resolution to your issue?

Re: ClusterXL - standby cannot reach gateway

Daniel_Bourne — Thu, 21 Mar 2019 14:25:42 GMT

Hello! We are having the same issue, were you able to get this resolved?

Thanks,

Re: ClusterXL - standby cannot reach gateway

Vincent_Van_Bru — Wed, 26 Jun 2019 12:37:19 GMT

Hello,
was there any feedback from TAC on this ?
Thanks.

Re: ClusterXL - standby cannot reach gateway

Gregory_Link — Wed, 25 Sep 2019 22:39:14 GMT

We are having this exact same issue. Did anyone find a resolution? We have firewall appliances though and not VMs.

Re: ClusterXL - standby cannot reach gateway

Ruan_Kotze — Thu, 26 Sep 2019 06:55:06 GMT

Hi,

Have a look at my thread over here: https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/Connectivity-issues-from-standby-gateway-after-R80-10-gt-R80-30/m-p/62572#M4773

My issue occurred after upgrading the environment from R80.30. We ended up having to follow step 4 in sk43807 (also mentioned by @G_W_Albrecht ).

Thanks,
Ruan