- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
I know how I can delete access control layers (via Manage Layers) but I didn't find any capability to remove a threat prevention layer. I always get a name uniqueness error when I would like to publish my changes because I have two Threat Prevention layers with the same name. So how I am able to remove those?
Error Screen:
Thx for help
We took the conversation offline.
Apparently, when you uncheck "Threat Prevention" from a policy package, sometimes you could end up with an "orphan layer" with no easy option to delete it.
We will publish an SK with a workaround script soon. When we do, I will update this thread.
The fix for this problem is scheduled for the next releases.
The workaround for this problem, for now, is to simply select a different name for the newly created policy package.
Unlike access control, the threat prevention layers are automatically deleted from the system when they are removed from the policy.
From the navigation pane, right-click the policy or one of the layers and select "Edit Policy..."
You can also keep the layer and just change its name from that dialog.
Thx Tomer!
But this didn't happen in my case.
I removed the layer manually first without success and afterwards I also removed the whole policy.
The layer still exist when I create the policy with the same Name "Olis_Policy" again.
CP will create the first Threat Prevention layer automatically with this name "Olis_Policy Threat Prevention".
When I would like to publish I will get this error immediately:
So the old Threat Prevention layer still exists in the DB somewhere...
What happens if you create a policy with a Threat Prevention layer, delete the whole policy and recreate the policy with the same name again?
Do you experiencing such name uniqueness errors as well?
It's not supposed to happen.
Are you using the R80 version from checkpoint.com or do you have an Early Availability version installed?
Is this the list of steps?
- delete a policy package named Olis_Policy
- create a new policy package with name Olis_Policy, with the options Access Control and Threat Prevention checked.
- a new validation error is presented and blocks from publishing this session
Are you by chance using a Multi-Domain environment?
For some reason it happend 🙂
Yes, I am using the GA Version of R80 from checkpoint.com.
Exactly!
- I created a policy named Olis_Policy with option Access Control and Threat Prevention checked.
- Deleted this policy.
- Created a new policy named Olis_Policy again with option Access Control and Threat Prevention checked.
- Validation error appears
So it seems, the Threat Prevention layer deletion process didn't run well when I removed my policy...
We took the conversation offline.
Apparently, when you uncheck "Threat Prevention" from a policy package, sometimes you could end up with an "orphan layer" with no easy option to delete it.
We will publish an SK with a workaround script soon. When we do, I will update this thread.
The fix for this problem is scheduled for the next releases.
The workaround for this problem, for now, is to simply select a different name for the newly created policy package.
Thx Tomer!
Oliver Locher
Solution Architect
T +41 43 833 15 49
M +41 78 630 33 33
F +41 43 477 70 12
oliver.locher@nttcomsecurity.com<mailto:oliver.locher@nttcomsecurity.com>
www.nttcomsecurity.ch<http://www.nttcomsecurity.ch/>
has the SK been already published for this? I have couple of orphan layers which can not be deleted.
I cloned Policy package with Inline Layers and than deleted cloned Policy package. Inline Layers were not deleted and are referencing deleted Policy package, thus it is not possible to delete them.
Thx
Juraj
Hi Juraj,
did you get any feedback/solution ?
We have the same issue and TAC is still pointing to the wrong direction, they believe SK107974 should solve the problem.
Matthias
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
24 | |
16 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 |
Tue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureTue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFTue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY