Five Habits That Improved My Check Point Deployments

[israelfds95]

Over the past few years, I've had the opportunity to work full-time with Check Point deployment projects, participating in hundreds of firewall implementations ranging from small environments to large enterprise deployments.

Every project has taught me something new. Some lessons came from successful implementations, while others came from unexpected situations that forced me to improve my planning and execution.

I'd like to share the workflow that has helped me consistently deliver successful projects.

1. Understand the Project Before Touching the Firewall

When a new project arrives, the first thing we usually hear is something like:

• "We'll deploy two Quantum gateways."
• "We'll deploy 30 Quantum gateways."
• "We'll deploy SD-WAN"
• "It's a Maestro environment."
• "We're migrating from another vendor."

But that's only the beginning.

Before writing a single command, I try to fully understand the environment:

• Physical topology
• Logical topology
• Existing routing
• WAN connections
• VLAN design
• High Availability architecture
• VPN topology
• External integrations
• Management architecture

The firewall is only one piece of the environment.

Understanding how everything connects together makes planning much easier.

Tip: Never leave the planning phase with unanswered questions. Every unanswered question has the potential to become a production issue during implementation.

One thing that still surprises me: many environments still don't have an updated network topology diagram. Good documentation is one of the best investments any IT team can make.

---

2. Spend More Time Planning Than Implementing

After understanding the environment, I start writing the Method of Procedure (MOP), or what we call the Executive Project.

This is where I invest most of my time.

A well-written implementation plan dramatically increases the chances of a successful deployment.

My planning includes much more than firewall configuration.

I verify items such as:

• Hardware models
• Interfaces
• Transceivers
• Rack rails
• Power requirements
• Cabling
• IP addressing
• Security policies
• NAT
• VPN configuration
• Virtual machines (when applicable)
• Rollback procedures

I also create both:

• Current topology
• Future topology after implementation

Physical topology diagrams are just as important as logical ones. During implementation they help distinguish firewall issues from switching or cabling problems, making troubleshooting much faster.

---

3. Study Before the Maintenance Window

Even after years of experience, I still review the implementation before every project.

I revisit:

• Commands
• Best practices
• Documentation
• Configuration examples
• Known limitations
• Upgrade paths
• Release notes

If there is something I might need during implementation, I prepare it beforehand.

The goal is simple:

Don't waste valuable maintenance window time searching for information.

---

4. Always Keep Documentation Available Offline

This lesson came from experience.

Not every data center has reliable Internet access.

Some environments have no external connectivity at all.

Before traveling to a customer site, I download everything that might be useful:

• Administration Guides
• Installation Guides
• SK articles
• Release Notes
• MOP
• Customer documentation

Having everything available offline has saved me multiple times.

5. Execution Is Where Preparation Pays Off

Implementation day can be stressful.

Many projects involve critical infrastructure, maintenance windows, and environments where downtime has a significant business impact.

It's normal to feel some pressure.

That's exactly why I dedicate so much time to planning.

When the maintenance window begins, I don't want to be thinking about what to do next.

I want to execute a plan that has already been carefully designed and reviewed.

Good preparation reduces stress and increases confidence.

---

Final Thoughts

Every engineer develops their own workflow over time.

The process above isn't the only correct approach, but it's the one that has consistently worked for me across hundreds of Check Point deployment projects.

Technical knowledge is essential, but successful implementations also depend on planning, documentation, communication, and preparation.

I'm curious to hear from the community.

What practices have helped you deliver successful Check Point deployments?

[simonemantovani]

I agree with you @israelfds95 , what you wrote is probably the best way to work, unfortunately, for my experience, most of the time  this approach is far from the reality, where the customer considers the installation of a firewall comparable to installing a PC.

I like to prepare and planning every job before before pressing the keys on the keyboard, and I thing that all the five steps are the right way to work.

[Amit_Navon]

So true @israelfds95 , the return on investment in planning and scoping is huge.

It save time and money and allows wins for customer, partners and check points.

Environments today are more complex, so even more important.

BR, Amit

[WiliRGasparetto]

Excellent post!

One point I'd add is the importance of validating the architecture before validating the configuration. In many deployment issues, the firewall isn't the root cause routing, asymmetric traffic, VLAN design, MTU, or external dependencies are. A well-defined MOP, rollback plan, and pre-validation checklist significantly reduce implementation risk and make troubleshooting much more efficient. Planning is often the biggest differentiator between a successful deployment and a long maintenance window.

[Duane_Toler]

100% echo:  "keep documentation offline"!  I have, and regularly update, my own repository of the Check Point documentation package AND the updated guides in that package.  This has been very beneficial.  I wish the writers would regularly update the complete package, perhaps quarterly.  It would be a significant quality improvement so we didn't have to go hunting for every admin guide.

I also keep offline copies of numerous ATRGs and SK articles that I find relevant and subject to repeat visits. Same reasons as mentioned.

I also 100% echo, and would extend: "no unanswered questions".  Ask EVERY question you can imagine, even for the smallest details (what type of ethernet cables, or fiber cables, are you using? Do your switches have auto-negotiation disabled? Do you need NEMA-5-15P cables, or C13? or now C19? How do you expect to handle authentication? Is TLS needed, and what ciphers?).  Try to imagine the stupidest scenario and most silly situation; someone has that configuration!   I tell my daughter: "if you can imagine it, someone somewhere has already done it".  Be very creative! 🙂

Indeed, have diagrams and documentation.  Your own creations will also go back into the customer's own documentation.  Multiple diagrams are advised:  Layer 1, Layer 2, and Layer 3.  These are not the same thing.  If you have the ability, also a Layer 7 diagram to show the expected application or process sequences, not just a wall of text describing it.

Engineers follow a spec they were given; Architects go around kicking every rock and pebble looking for trouble.  Be an architect; if you're irritating everyone, then you're doing it the right way!

[Magnus-Holmberg]

Its often that these kind of implementation documentation is saved in some sort of project.
Then when you need it 1-2 years later, its nowhere to be found as the engineers installed it has moved on.

When doing planning, documentation etc
Do that in a system that is used within production for your documenation.
We for example uses Netbox for all the physical stuff and the things that is "non standard" to have it easily accessible in day to day operation when its time for the next upgrade / tshoot. 

Ofc its good if your standard is then well documented, but i still find it more useful that you make sure to document things that was changed from default settings, IE: 00-OS-XX.rules  / user.def or similar files.