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

Gateways Loose Internet Connection After Policies Intallation

Hello Mates!

I'm having a strange problem in a client's environment. It's a Cluster in HA R81.10 Take 94.

When I install policies, the gateways lose communication with the internet, there's no ping to the outside, but the machines behind the gateway navigate normally.

When I apply an fwunloadlocal to the gateways, they start responding to ping from the internet again, but the machines stop browsing.

No drops are shown in zdebug, the policies rules seems to be ok too.

fw monitor show like this when I try to ping external address:

fwmonitor-gw.png

the IP 172.31.1.3 is the gateway interface. I just see the request, not reply

In the same moment that a machine behind the gateway shown me request/reply normally:

fwmonitor-pc-behind.png

What could be causing this?

0 Kudos
1 Solution

Accepted Solutions
Bernardes
Advisor
Advisor

Hello friends @the_rock @Blason_R 

Thank you very much for all your help and dedication so far!

The problem has been solved with a NO NAT rule on the Check Point.

nonat.png

As I mentioned before, this Check Point appliance didn't perform NAT, the NATs were configured on the F5, and it has worked like this since deployment.

I believe something was changed on the F5, and out of curiosity, I created rules for the members' IPs and the cluster's VIP, and after creating the rules, the appliances navigated normally.

nav.png

However, I didn't understand why it worked without the policies. Was there something implicit that made it work?

Do you have any idea of what could have made the appliances' navigation work without the policies installed?

Thank you all!

View solution in original post

0 Kudos
14 Replies
the_rock
Legend
Legend

I had this happen with customers before and 9 times out of 10, either its something with topology (anti spoofing) and/or routing/nat.

Here is an easy thing to try...in both situations, run ip r g 8.8.8.8 from gateway and compare the output, that should give a clue.

HTH @Bernardes 

Andy

0 Kudos
Bernardes
Advisor
Advisor

hello @the_rock !

This was the result before and after fw unloadlocal:

unload.png

I try to disable anti-spoofing, but it doesn't work.

0 Kudos
Blason_R
Leader
Leader

Any changes in Implied rules? Did you disable anything?

 

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
0 Kudos
Bernardes
Advisor
Advisor

Hello @Blason_R ! The implied rules are default, no changes.

0 Kudos
Blason_R
Leader
Leader

Ok so what does fw stat shows if policy push is successful?

Do you get ping to 8.8.8.8 or 9.9.9.9

Do you get arp of your default gateway (arp -an | grep <DG_IP_Address>)

What is cphaprob -a if says?

cphaprob stat shows any PNOTES?

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
0 Kudos
Bernardes
Advisor
Advisor

@Blason_Rlook at the output results for these commands:

output-res.png

0 Kudos
the_rock
Legend
Legend

Ok, so thats the same...can you tell if nat takes place when issue occurs? What does zdebug show?

Andy

0 Kudos
Bernardes
Advisor
Advisor

@the_rockthe NAT occurs on an F5 appliance in front of Check Point. This Security Gateway is not doing NAT in this case.

In zdebug output not is showing nothing fot this traffic, apparently theres no drop

zdebug.png

0 Kudos
the_rock
Legend
Legend

@Bernardes Since I like to think about anything in life the logical way, lets recap this situation.

Sooo...IF you do fw unloadlocal and everything works fine, that tells me logically that SOMETHING in the policy is causing the problem. Can you do zdebug BEFORE you unload the policy and see if it gives anything?

Andy

0 Kudos
Bernardes
Advisor
Advisor

@the_rockThis zdebug output above is when the policies were applied, but after the fw unloadlocal the result is the same, aparently there's no drops before or after the policies are applied.

0 Kudos
the_rock
Legend
Legend

Ok...if you are 100% sure and you have verified routing/natting, then only other thing I could think of is anti-spoofing. Please ensure thats accurate, because if wrong, it can definitely cause issues like this one.

Take care.

Andy

0 Kudos
Bernardes
Advisor
Advisor

Hello friends @the_rock @Blason_R 

Thank you very much for all your help and dedication so far!

The problem has been solved with a NO NAT rule on the Check Point.

nonat.png

As I mentioned before, this Check Point appliance didn't perform NAT, the NATs were configured on the F5, and it has worked like this since deployment.

I believe something was changed on the F5, and out of curiosity, I created rules for the members' IPs and the cluster's VIP, and after creating the rules, the appliances navigated normally.

nav.png

However, I didn't understand why it worked without the policies. Was there something implicit that made it work?

Do you have any idea of what could have made the appliances' navigation work without the policies installed?

Thank you all!

0 Kudos
Blason_R
Leader
Leader

That nice to know that but still looks odd to be honest. The traffic originating from gateway does get hide or folded behind VIP and shouldn't matter if those are natted or not provided what is the sequence kept in global properties  for "Traffic originating from Gateway" <LAST|First| Before LASt>

And  without policy the appliance does not route the connection or no connection can traverse through the appliance for security reason else it will perform just like normal server.

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
0 Kudos
the_rock
Legend
Legend

I tend to agree with @Blason_R . Good job by the way in doing those rules, since F5 is handling the NAT. But, having said that, by default, CP firewall will not do any nat, as out of the box, nat is not enabled and plus, there is no default nat rule inside the policy that would nat all outgoing traffic, so one either need to be created OR you can check option to nat all internal networks behind the firewall external IP.

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events