Problem with SYNC Interface

[Matlu]

Hello, everyone.

Currently, I have a ClusterXL of 2 teams, "literally" is broken (There is a problem with 1 of the members, and only 1 is working).

We are recovering the injured member, but currently, having the member, the same version of GAIA, R80.40, and the IPs configured correctly, we can not validate "CONNECTIVITY" between the IPs of the SYNC interfaces (the tests we do is using the PING).

Then, I have problems to get the "wounded" member into the ClusterXL. I guess it is for the same reason, that there is no "communication" between the two SYNC interfaces.

It is important to comment, that the connection is direct between the 2 SYNC interfaces of the units, we only have a PATCHCORD that joins the 2 interfaces.

Could someone comment me, what type of additional tests, or how I could manage to discard an error of the SYNC interfaces?

I want to achieve communication between both devices, but at the moment it is not possible.

Best regards.

[Chris_Atkinson]

Have you reviewed the following command outputs for clues and do you see any traffic on the interface via tcpdump or similar?

show cluster statistics sync and cphaprob syncstat

[the_rock]

Hi @Matlu 

Can you please send us output of below commands from working and non-working member:

cphaprob roles

cphaprob state

cphaprob -a if

cphaprob list

cphaprob syncstat

Cheers,

Andy

[Matlu]

Hello,

Both IPs that appear in the TCPDUMP result, are the ones that belong to the SYNC interface of each of the devices.
The SYNC interface is Eth7.

I can't figure out exactly what the problem is.

The equipment is in the same version as the equipment that is working well, that is to say, in the version R80.40.

I have applied the command "fw unloadlocal" on the recovering Firewall, just to avoid any observation with it, but still, the problem continues.

Any suggestions please?

Regards.

[the_rock]

Just thought of something and Im fairly confident this could fix your issue. Do you have a rule in your policy that allows proper communication between cluster members? So, something like this...say cluster name is cp-cluster and members are cp-1 and cp-2, I would set up rule like below:

src:cp1,cp-2 and cp-cluster

dst: same as src

vpn:any

service:any

action:accept

log

Reason I say this is because if you look at below link, there are specific ports/services needed for cluster to work properly

Hope this helps

Andy

https://community.checkpoint.com/t5/Security-Gateways/R8x-Ports-Used-for-Communication-by-Various-Ch...

[Chris_Atkinson]

What does "show interface eth7" on both members show?

Per the previous thread that this is a continuation of have you engaged TAC as yet to assist/expedite.

[Matlu]

Hello,

Unfortunately, there are problems "administrative and management" of my client, hahaha.

The client has super old equipment "EOL", and apart from that, in its last renewal process, it turns out that these teams, no longer have a way to have "permanent licenses", therefore, no support from TAC, both for Hardware and Software.

The chips are burning now, hahaha.

This is what the recommended command shows me, in both Firewalls (the one running inside ClusterXL is the one with the grey background).

Regards

[Matlu]

Hello, Andy.

Result of the commands applied on the member, which is working well.

Result of the commands applied to the member, which is NOT working properly.

Both members are in the same version, R80.40.

Thank you for your help.

[the_rock]

WAIT A SECOND...I see on the other member it shows there are no sync interfaces, which makes sense why it does not even show in cphaprob state output at all. Can you verify that sync is indeed enabled on that firewall? Either via clish or web UI?

For example, if you log into web UI, just navigate to interfaces and see what sync shows, which there should be dedicated sync interface, called Sync. Otherwise, just go to clish and run show interface Sync

[Matlu]

Hi, Andy.

Result of browsing the member's WebUI that works fine.

Result of browsing the member's WebUI which is NOT working properly.

The only difference I see is that the member that works well has a "comment" added that says SYNC, nothing more than that.

Do you think I'm missing something?

[the_rock]

No, that looks okay to me. Here is the question then...does customer see in topology that sync is defined there as well? Can they succefully do "get interface without topology"?

[Matlu]

Andy,

I get this result.

I enter the OBJECT of my Cluster, from the SmartCenter, and when I try to call the topology, I get this ERROR message.

[the_rock]

I assume there is probably no policy on the fw 1 at the moment? Lets do remote tomorrow if you are free...I looked up the external IP and it shows Peru, so its same time zone as EST. Peru, beautiful country btw : - )

Anyway, let me know.

[the_rock]

I may have some time today at 3 pm as well if that works for you, because I really need to see this for myself. I mean, Im 99.99% sure whats going on, but easier via remote session, if your customer allows it.

[Matlu]

Sounds great,

How do we proceed?

I've never had a chance for a session, hahaha.

Can this be coordinated privately?

Regards.

[the_rock]

Of course : - ). I did remote session with people on here before. Trust me, I still REMEMBER how difficult it was when I started with CP 15 years ago and sadly, there was not much help around, so that always motivates me to help as much as I can. Anyway, message me directly and we can set it up. I am just busy for next 2 hours or so, but should be free after. I will respond as soon as I can.

[AaronCP]

@Matlu I've had a remote session with@the_rock before for an issue I was experiencing - seize the opportunity, he knows his stuff 🙂

[the_rock]

Thats what she said and she was right ;). Just kidding...anyway, we will have to use google translate, since he speaks Spanish and my Spanish is ABYSMAL, so lets see if we can fix it : )

As my good friend would say "Andy, you talk fast, so people think you know what you are doing" hahaha, thats definitely true LOL

[the_rock]

Thanks mate, you are an amazing dude too, it was pleasure to help you!

[the_rock]

Dont mark my answer as solution, its NOT a solution brother, haha. Lets see if we can fix it first and then we can mark the post as solution. Point is if someone else has same problem, they can see how it was fixed.

Cheers.

[the_rock]

Latest update...did remote with @Matlu and this to me does not appear to be fw issue itself, but rather than upstream router and here is why.

So, even without any policy loaded on the fw, we cant ping google dns, load the policy, reset sic and when we try to even ping default gateway to the Internet it fails, so of course nothing else will work. As @Matlu said, customer knows this issue with the router, so it makes no sense to waste time and keep rebooting CP appliance, because it wont do a single thing at this point.

@Matlu , PLEASE show what we did to the customer and tell them this is the issue. Think of this way...if your ISP provider's router at home was not pingable from say your desktop, of course your desktop will never be able to get anywhere outbound.

Keep us posted on what they say. 

Thanks again for your time over remote.

Cheers.

[Matlu]

Thanks for your help, Andy.

A doubt, or rather curiosity, the equipment that is now working well, is "exposed" to happen the same thing that is happening to the member that is "spoiled"?

This Cluster of Firewalls, are the perimeter of the headquarters, if something happens with the only one that is working, the client will be "completely" down, right?

Thanks for everything.

[the_rock]

Hey amigo : - )

OK, so here is the esence of it. Dont think of a cluster at this point, because there is no cluster, so to say. Its single member as the other one is not synched to it and not even getitng any heartbeat at all. Here is the thing...ask customer below:

1) where does it fail when even trying to get to default gateway?

2) can they verify layer 2 connectivity?

3) check for any differences between 2 members? Keep in mind, we are NOT even getting to layer 3 here, so they need to verify exactly why member 1 works and the other one does not.

And you are welcome, for you, no charge ; - )

Keep us posted on the progress and you know where to get a hold of me.

[the_rock · Accepted solution]

Just an update to the actual solution for this issue.

@Matlu made another post related to this and @Sorin_Gogean pointed out that subnet used was wrong.

https://community.checkpoint.com/t5/General-Topics/Routing-problem/m-p/173004#M28869

Always something to look out for.

Huge thanks to Sorin for noticing that, as its super easy to overlook, for sure.

Great job everyone!