How ping works with a ClusterXL?

[Thomas_B]

Hi all,

I have a question about the ping with a Cluster of 2 appliances.

I have the following situation

Switch 192.168.1.1 and 192.168.1.2 are connected.

Appliance 192.168.1.252 is active and 192.168.1.253 is standby.

From the appliance 192.168.1.253 (standby) I can ping 192.168.1.1 and 192.168.1.2.

But I had an issue and the link between 192.168.1.1 and 192.168.1.2 is down like it's following:

The appliance 192.168.1.253 still be the standby one. For it, I can ping 192.168.1.1 but not 192.168.1.2.

I can ping 192.168.1.2 only when 192.168.1.253 is active.

When I check with fw monitor I saw "o" with 192.168.1.253 and "O "with 192.168.1.254 that is carried by the active appliance (192.168.1.252).

So when I am pinging with the standby appliance, the ping is going out thru the active appliance?

Is there a way to force the ping to go out with the 192.168.1.253 IP and by its interface not the virtual?

Is there a way to make ssh to 192.168.1.2 without putting 192.168.1.253 active?

Thank you!

Thomas

[Ricardo_Gros]

Hi, 

You should check out this SK Simultaneous ping and to force the source to be the physical IP you could create a No-Nat rule for example. 

[Jelle_Hazenberg]

I recommend you to read this article https://www.51sec.org/2015/07/checkpoint-standby-cluster-member-interface-not-reachable/ so you have a understanding of what is happening if you have this behavior, this article describes it from the other direction but there is also a part where it describes "in some cases when the traffic originates from the standby member, return traffic is forwarded from the VIP to the active member, which drops that traffic.“ i think you are experiencing the same issue. Also there are several SK's describing this. Depending on the version you are running on the gateway's the kernel parameter on R80.10 is set to fwha_forw_packet_to_not_active = 1 and fw ctl set int fw_allow_simultaneous_ping is on by default if i am not mistaking. Let me know if this was the solution. What does a fw ctl zdebug tell you?

[Thomas_B]

I didn't try zdebug. I will do.

My problem is that currently i can't make ssh from standby appliance to my switch without setting it active and currently I can't set it active because the external connection works only on appliance active.

[Gaurav_Pandya]

Hi Thomas,

Do one thing. SSH to your Active firewall, and try to SSH passive firewall from active firewall. It should work.

After that do setting which Jelle has suggested.

fwha_forw_packet_to_not_active = 1

[Jerry]

and what are the SYNC IP's?

are you sure your "object" has properly configured SYNC interface (what is the cphaprob -a if showing you?)

[Thomas_B]

Sync is on 172.16.1.0/30 with 2 IPs

the cphaprob state is good

[Thomas_B]

Extract of fw monitor -e 'accept host(192.168.1.2)'

[vs_0][fw_0] eth3.100:o[84]: 192.168.1.253 -> 192.168.1.2 (ICMP) len=84 id=0
ICMP: type=8 code=0 echo request id=22807 seq=1
[vs_0][fw_0] eth3.100:O[84]: 192.168.1.254 -> 192.168.1.2 (ICMP) len=84 id=0
ICMP: type=8 code=0 echo request id=10213 seq=1

[vs_0][fw_0] eth3.100:o[84]: 192.168.1.253 -> 192.168.1.2 (ICMP) len=84 id=0
ICMP: type=8 code=0 echo request id=22807 seq=2
[vs_0][fw_0] eth3.100:O[84]: 192.168.1.254 -> 192.168.1.2 (ICMP) len=84 id=0
ICMP: type=8 code=0 echo request id=10213 seq=2

[Thomas_B]

fw ctl zdebug + drop | grep '192.168.1.2'
;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=1 192.168.1.2:0 -> 192.168.1.253:0 dropped by fwha_select_ip_packet Reason: icmp probe reply to our request;

[Thomas_B]

It's not possible to says ping 192.168.1.2 with interface eth3.100 and your physical IP?

[Ricardo_Gros]

Hi, 

I just now realised you have this issue only if the trunk link is not available.

I would definitly try to have redundancy on swith level, 2 trunk Port would be advised... 

Try a no Nat rule from physical IP of passive appliance to switch this should Make the Ping and the ssh work, but having no trunk will create other issues... 

[Thomas_B]

Yes you are right, the issue is only when the link between the 2 switches is down.

This is why I think that when the standby what's to talk, all the trafic goes thru the active member.

So you think that a no nat will work?

[Jelle_Hazenberg]

Hi Thomas,

I am guessing that you enabled the option "hide internal networks behind the Gateway's external ip"? 

Please disable this option and try again.

**ATTENTION** 

Keep in mind that if this is production you have to create NEW NAT rules for all the traffic that needs to be NATted because this would disable the implied rule. Before disabling please be sure that you don't need this option anymore. Best way in my opinion is create a lower MANUAL NAT rules that will do the same but where you exclude both cluster members.

[Thomas_B]

No it's disabled