- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: Policy verification fails with Data Center obj...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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# | Source | Destination | Service | Action |
100 | 10.0.0.0/8 | sg-aaa, sg-bbb | Any | Accept |
... | ||||
200 | 10.0.0.0/8 | sg-ccc | Any | Accept |
... | ||||
300 | 10.0.0.0/8 | sg-ddd, sg-eee | Any | Drop |
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.