Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Srdjan_B
Collaborator
Collaborator

Policy verification fails with Data Center objects

We noticed a strange issue with policy verification (R80.40). The policy is heavily AWS dependent, more than 50% of all rules are using AWS security groups either as a source or a destination. Here is example of some of the rules:

Rule#SourceDestinationServiceAction
10010.0.0.0/8sg-aaa, sg-bbbAnyAccept
...    
20010.0.0.0/8sg-cccAnyAccept
...    
30010.0.0.0/8sg-ddd, sg-eeeAnyDrop

 

Verifier complains that rules 100 and 200 conflict with rule 300. Security groups are different, and they are not empty.

Strangely, policy installation succeeds. Furthermore, running policy verification after installation succeeds as well.

Any ideas why is this happening and how to avoid it? Thanks.

 

0 Kudos
4 Replies
Nir_Shamir
Employee Employee
Employee

I am guessing rule 300 NSGs contain IP addresses from rule 100 and 200 NSGs.

try moving rule 300 over 100 and 200 , especially when the Service is ANY

0 Kudos
Srdjan_B
Collaborator
Collaborator

Thank you, but that is not the case. Rule 100 is related to one application, rule 200 is related to another and rule 300 is related to third application. They are not sharing any VMs, there are no IPs from rule 300 which belong to SGs referenced in rules 100 and 200.

It happened multiple times (example is simplified, there are 50+ rules like the examples above as there are 50+ applications).

Basically, for application CCC, we have detailed, specific rules 190-199 and the permissive rule 200. Rules 190-199 are there to permit what we know is required. Rule 200 is temporary rule, we use it to check if something was missed. Once we are confident that rules 190-199 are sufficient for that application, we will change action on rule 200 to drop. And after that, if we do explicit verify, it complains that 200 conflicts 100. If we push policy, it gets verified and installed on gateways. Next verify is successful too. 

If something was wrong with the policy, I would expect installation to fail too. Also, doing explicit verify after policy push is successful and policy is identical to the one when it failed. 

And last, customer has upgraded management to R81 and we see the same behaviour.  

0 Kudos
PhoneBoy
Admin
Admin

If anything, we liberalized the policy verification rules in R80.40 and above.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

The fact it's failing at all in this instance is a bug (worse, it's doing so inconsistently).
Looks similar to this bug: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Recommend a TAC case.

0 Kudos
Srdjan_B
Collaborator
Collaborator

Thank you, this looks very similar to what we have seen few months back (with actual IA rules and access roles). But it happened once and never came back, so we did not continue investigation.

Since Data Center objects are based on IA, it is quite possible this is related. I will check if customer is willing to invest time in further investigation and opening SR.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.