Cannot access Web GUI checkpoint firewall in cluster

[Vu_Le]

Hello and happy new year everyone,

I have two checkpoint firewall running cluster active - active, I want to configure new interface, but I only access web GUI one checkpoint firewall, number two firewall access log on smart console inform deny connect.

Someone can help me to fix it.

Thanks you.

[Danny]

Are you connecting via VPN? Please show us rule #10.

[Vu_Le]

I have allow this traffic.

[Chris_Atkinson]

Hello, 

Could you please confirm some more details of the topology... where is the source address 172.18.95.X located in relation to the destination interface IP (172.18.6.X) that you are attempting to connect to?

Some related solutions that may help isolate the cause are provided below for reference.

sk119154 - Cannot connect to the Standby member from a non-local subnet
sk106425 - Connections through cluster to physical IP address of ClusterXL member are dropped by Anti-Spoofing

sk42733 - Connection from one side of the ClusterXL destined to the physical IP address of a non-Active cluster member on the other side of the ClusterXL fails

[Vu_Le]

Hello Chris,

Pls see topology, all source network in vlan on checkpoint firewall.

[Steve_Runyon]

If you check the log you might find that your connections to the inactive cluster member are getting dropped as out-of-state or spoofed. Likely, your connection to the inactive member and the return traffic from it are on different interfaces on the inactive member. Traffic _to_ the inactive  member wants to go via the active member.

How I fixed this in my environment was to put static routes on the internal router that is adjacent to the cluster.

Suppose your mgmt segment is 10.2.65.0/24 and those are the addresses you are connecting to with the web GUI.

And, 10.2.44.0/24 is the backbone segment between the gateways and your adjacent internal router.

Let's say 10.2.65.1 and 2 are the mgmt IPs of the two gateways, and 10.2.44.5 and 6 are the IPs of (say) eth1 of the two gateways.

Router has:

ip route 10.2.65.1 255.255.255.255 10.2.44.5

ip route 10.2.65.2 255.255.255.255 10.2.44.6

If you don't do this, this adjacent router sends all of the traffic for dest 10.2.44.0/24 to the active member. The traffic might still reach the inactive member after coming out the other side of the active member, but the reply from the inactive member will come out a different interface on it, hence will be dropped.

[Vu_Le]

Hello Steve, 

I give a little more information, I can still access IP real management of Gateway01 but not Gateway02, so I just run one command add route?

[crescentwire]

(My apologies in advance if this isn't exactly your issue, but I wanted to put it out there all the same. Otherwise, please disregard.)

I had a similar case open with TAC about this, but for me it was on a ClusterXL setup with dual 13800 appliances. TAC was able to reference sk43346 with the following fix:

Run the following command in expert mode from both gateway CLIs:

[Expert@gateway]# fw ctl set int fwha_forw_packet_to_not_active 1

What this does is tell the cluster to permit answers from the secondary ClusterXL member, even though there hasn't been an HA state change.

I hope this helps you out. This was a major irritation for us for a long time before we finally discovered, with TAC's help, the actual fix.

(Please note that I am hereby NOT responsible for an outage if you apply this command in your environment without thoroughly reading and understanding the sk I referenced above. Please do your due diligence and don't take my word for it alone!)

[AlekseiShelepov]

fwha_forw_packet_to_not_active is one of very often recommendations in cases like this. There should be no outage because of it. Also, the command that you provided just changes the parameter until a reboot. The parameter should be written into fwkern.conf file, if it is required.

More details and information are available in previous threads:

Problem accessing standby cluster member from non-local network 

Checkpoint Standby Cluster is using VIP to communicate with outside 

With routes added (as Steve mentioned above), it also should work. But I prefer to change the kernel parameter, as it helps with many other situations.

[Vu_Le]

Thanks you, I'll try, but this device need working  24/7, so I need plan to resole, can you tell me the problem, issue that may be encountered and estimate downtime.