Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Matlu
Advisor
Jump to solution

Problem with SYNC Interface

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.

1 Solution

Accepted Solutions
the_rock
Legend
Legend

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!

View solution in original post

23 Replies
Chris_Atkinson
Employee Employee
Employee

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

 

CCSM R77/R80/ELITE
the_rock
Legend
Legend

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
Advisor

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.

ClusterXL8.jpg

ClusterXL9.jpg

the_rock
Legend
Legend

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
Employee Employee
Employee

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.

 

CCSM R77/R80/ELITE
Matlu
Advisor

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).

Eth7_M1.jpgEth7_M2.jpg

Regards

Matlu
Advisor

Hello, Andy.

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

CL1.jpgCL2.jpg

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

CL3.jpgCL4.jpg

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

CL5.jpg

Thank you for your help.

the_rock
Legend
Legend

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
Advisor

Hi, Andy.

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

CL7.jpg

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

CL6.jpg

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
Legend
Legend

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
Advisor

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.

CL8.jpg

the_rock
Legend
Legend

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
Legend
Legend

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
Advisor

Sounds great,

How do we proceed?

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

Can this be coordinated privately?

Regards.

the_rock
Legend
Legend

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
Advisor

@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
Legend
Legend

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
Legend
Legend

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

the_rock
Legend
Legend

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
Legend
Legend

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
Advisor

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
Legend
Legend

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
Legend
Legend

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!

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events