Routing problem.

[Matlu]

Hello, team.

I have a question.

I have a route created in 1 GW, to reach an IP.

The command netstat -rn, tells me that the route is created correctly, since the traffic to reach that particular destination, must be reached by the ETH5.

The problem is that when I check with the command "ip route get 10.49.2.218", to see where the traffic is actually going out, this command tells me that the traffic is going out on ETH1, and I find it super weird. (Obviously, the connectivity test is not satisfactory).

P.S.: Eth1 is the interface to the Internet.

I have version R80.40 with JHF 180.

Any idea why this could happen?

Regards.

[Sorin_Gogean · Accepted solution]

Hello,

You have a Routing problem as the 10.49.2.0/26 doesn't cover the 10.49.2.218 you're looking to get to.

An /24 would cover but not as it set today, so your assumptions are wrong.

Enjoy,

[Matlu]

Hello,

I am going to try your recommendation, hopefully I will get success.

I will change the segment with /26 for a /24, and according to your theory, this should work, right?

I will try it, and let you know the results.

Cheers.

[the_rock]

100% it would cover that IP address.

[Sorin_Gogean]

Hi,

Honestly I could sound rude for some, but @Matlu if you're not aware what netmask does and how it's applying to routing, then I would recommend to drop the firewall alteration stuff and go and re-read/document on IP and routing. 

That was not my recommendation but me pointing the error .

Thank you, 

PS: if you do things in production without being able to understand how things are interconnected (I was to say "how things are working") then you need to stop and let others do it... 

PS2: if you need to clarify some questions, concern, then ask, but for basics....

[Matlu]

Hello,

Thank you for your comments, but I transmit you the "why" these "innocent and silly doubts, perhaps" appear.

It turns out, I have another computer, it is a computer, which has the same route, for the same destination, with the same mask /26, and what is the difference?
That this route, if it "works", if it applies, and if it respects, what is configured.

It turns out that the team that I'm trying now, is a team that had a problem, and "unhooked" from the ClusterXL in which it was.

Then, the routes are being replicated, as they have the equipment that is working.

Do I understand?

I am sharing evidence of the computer that is working well, which is part of a Cluster, and the other computer, for which we are now working, and does not "respect" the routes, well, it is a computer, which is practically, "copying" the Firewall that is good.

I hope to sound more convincing now.

[Chris_Atkinson]

But you are not showing the complete routing table from the other device?

The IP address is outside the subnet mask boundary in question, period.

[Matlu]

Hello,

In the shared images, this is the difference.

The equipment that works well, and the one that is failing, both have the same path, with /26.

In 1 of them, the route, if it works, in the other one, NOT.

Greetings.

[the_rock]

I remember you showed me same over remote session and screenshots you sent via email, but guys are right, it is WRONG and subnet should be fixed. Why it works on the other member, I have no clue, but again, its incorrect.

[Matlu]

I just did the test, Andy.

Yes it works, changing the "/", now the route, in the bad GW, has the /24, and yes I have connectivity.

The problem and my existential doubt is, why in the Firewall that is working fine now, if it works with the /26?

Is it to pull your hair out?

HAHAHA.

What the hell 😄

[the_rock]

Well, not to sound ironic now, but lots of things that are not supported sometime work, but still does not mean thats the way it should be. Same if you told me "This worked yesterday", my answer to you would be as to anyone else "Thats right, and I was day YOUNGER yesterday" 😉

Andy

[Chris_Atkinson]

show the full table for comparison or atleast expand your grep to the next octet...

[Sorin_Gogean]

Hello @Matlu ,

Sorry but your previous questions are not so innocent, since in my eyes shows lack of knowledge on network side.

Don't get me wrong, but IP and Netmask are bread-and-butter in networking, I really hope someone can prove me otherwise 😊, therefore I can't accept it.

Now on the routes, YOU CLEARLY DON'T HAVE SAME ROUTES ON THOSE BOXES (sorry for shouting), I mean really, on the WORKING box you show 3 routes while looking for the 10.49.2 (from which 2 are in discussion) and on the FAILING box you only have one... It's clearly visible right there.

Now with all those facts, and with you stating "Yes it works, changing the "/", now the route, in the bad GW, has the /24, and yes I have connectivity." strengthens my doubts, that you're not clear what are you doing there. So please either COMPARE and REPLICATE the routes between boxes, and take the WORKING box as reference, but don't add things that you don't know the impact of.... 

Thank you,

PS: I would "pull my hair out" for lack of knowledge, or due to that....

PS2: honestly, go back and gain knowledge to the bread-and-butter, it's good for you, not for me as I have my own baggage and learning path, since I started 😁

PS3: routes on GAIA do not replicate and you have to maintain them on both boxes....

PS4: get me a topology map and I could tell you more, as there are some things that doesn't make sense right now in this whole story with the SYNC and all others....

[the_rock]

Also, keep in mind, @Matlu has to use Google translate to translate from Spanish into English, so that makes it way more difficult to explain all this. He is a good guy, I got many emails from him about this issue, its not easy when end customer does not provide everything thats needed.

[Sorin_Gogean]

@the_rock , yes I got that, still the pictures shows exactly what's what, and initially I thought he missed seeing them, due to reasons (tiredness or smth else) but still coming 2nd and 3rd time with "basic" questions, those are red-flags for me. 

I'm not doubting that we're all good guys, and well intentioned, but in some cases it's not about that 😊.
Always, I'll help and talk/guide base on things I encountered through time, no issues there, as I'm also asking for others to support 😁.

As for missing information from customer side, that is understandable, and you'll have to do your best with what you have ,  I totally get that .

[the_rock]

I get all you are saying...

[Matlu]

Thanks for "armoring" me, Buddy 😄

It has been a good experience for me.

I must keep learning, and improving.

Thanks for your time, help and patience.

Best regards.

P.S. It was indeed a Firewall routing problem.
I have added the Network 10.49.2.219/26 and now it works.

Obviously it also works if I only put the network 10.49.2.0/24, HAHAHA.

What a COOL experience 😄

[the_rock]

Thats why I said you are good dude! Anyway, as long as we learn from our mistakes, all good. By the way, if you ever need help with https inspection, @Sorin_Gogean is the person to help, he is EXCELLENT 👌

[Matlu]

I have learned my lesson, my friend.

It was a lack of knowledge on my part, to better understand the client's network, maybe he doesn't even know how he has his network, and is a bit disconnected from his environment.

This experience has taught me many lessons.

Thank you for the acid comments, HAHAHAHA, those help me to improve as a professional and even more, as a person.

Thank you very much. 🙂

[Sorin_Gogean]

@Matlu , I get it and I'm glad you didn't felt offended.

Like I said, I'm active on this forum to help others and to ask my dumb questions too.

So whenever you have questions or concerns, either post or send a message, I don't mind helping others 😊.

PS: my previous request still stands, show us a topology and the faced issue and we'll be able to help more.

[Matlu]

I comment,

After leveling the routes (REALLY, "COPY" the routes of the Firewall that was working), everything started to work fine.

Even, the communication between the SYNC interfaces (ETH7), and now, I managed to hook the GW to the Domain.

Then, the ClusterXL is already "armed" again.

All this, after replicating the routes, as you suggested.

At the moment, the routes in the broken equipment are like this.

It was really a problem of "understanding" the customer's network scheme better.

This teaches me that it is better to know the network of an environment, than the network owner himself, because when the "chips are on fire", they "don't know anything", HAHAHAHA.

[Sorin_Gogean]

@Matlu, Glad that you've figure it out .

Now that is fixed, see with the customer that the persons able to perform changes on the appliances, are less then X, where X is for them to determine. Otherwise this situation will come again (hopefully not). 

[the_rock]

Glad its all working as expected. Thats best thing about communities like this, we all work as a team to find the answer for the customer. No judgments, even smallest/simplest mistakes can happen, nothing or no one is perfect.

Good job @Matlu and huge thanks to @Sorin_Gogean for pointing out the actual solution. I will update your other thread as well.

Cheers,

Andy

[the_rock]

I think @Sorin_Gogean is right...

 

[the_rock]

By the way, I think its related to your post from couple of weeks back? : - )

https://community.checkpoint.com/t5/Security-Gateways/Problem-with-SYNC-Interface/m-p/171796#M31196

Here is my message...all the Spanish I learned in Paraguay and Argentina, haha

Si hay un problema amigo, consique una margarita...so true : - ))

[Matlu]

Hi, Buddy 😄

Exactly, it's related to my penultimate post. HAHA.

The client is a chaos, and now we are "shielding" the Firewall, before they "burn" it, HAHA.

Cheers

[the_rock]

HAHAHA...fair enough ; - ). You may need more than 1 margarita in that case lol