Switched from Sophos XG to Quantum 3600 - the CLI is a nightmare in comparison.

I'm a senior sysadmin at a mid-market MSP that manages about 300 client sites; we standardized on Check Point Quantum appliances for our own core network and for a subset of our security-focused clients, but I've had hands-on with Sophos XG at several acquired shops.

Here's the breakdown from someone who bills hours for this work:

1. **Target user:** Sophos XG is built for admins who live in the CLI. Check Point Quantum is built for architects who live in SmartConsole, with CLI as a break-glass tool. If you're a team of 1-2, that philosophical difference is a daily tax.

2. **Real deployment effort:** The initial policy migration took us roughly 40 hours per appliance for similar-sized rulesets, mostly translating flat rules into Check Point's object model. You'll script it or lose a week. The CLI is not built for bulk operations; you'll use the API or R80.x migration tools.

3. **Where Check Point wins concretely:** The consolidated logging and threat forensics. In my stack, the 3600 handles about 1.8 Gbps of inspected traffic with all blades enabled, and the correlation in SmartView is something Sophos Central couldn't touch at the time. You're paying for that single pane.

4. **Hidden costs:** Licensing complexity. A Sophos license is straightforward. A Check Point SKU with all threat prevention blades, plus support, on a 3600 came in around $28k/year for us. Miss a blade and a feature is just missing. CLI proficiency requires their $3k+ admin course; you'll be Googling the clish syntax weekly.

For a network where the primary administrator prefers a CLI workflow, I'd recommend staying with Sophos. If you have a dedicated security team that uses the GUI for deep investigation and needs the granular reporting, stick with the 3600 but budget for formal training. To decide, tell us your team size and whether you need the forensics dashboard daily or just need a firewall that passes traffic.

Oh wow, this is exactly the kind of thing that scares me about making big vendor switches. When you said "simple 'deny ip any any' style logging," I felt that. In Sophos, you just do it. The object-centric model in the CLI sounds really intense for quick tasks.

So, is the CLI mainly for emergencies or minor tweaks? Are you basically forced to use the SmartConsole for any real change? Sorry for the basic question, still learning the ropes here. Thanks for the heads-up

You're right about the object model being the core of the friction. It's not just a syntax change, it's a fundamental design choice. The CLI expects you to work within the architecture of the management database, which is why every action feels like a multi-step process.

That said, once you internalize that everything is an object, you can start scripting in clish more effectively. You can't fight it. The quick wins come from learning to use `add object` and `set object` commands as your first step for any new host, network, or service before you even touch a rule.

For the running config clarity, try `show configuration full`. It's still not a clean hierarchical dump like you might be used to, but it gets you closer to a complete picture without jumping between sub-menus.

That's a solid point about internalizing the object model. It really is the only way to work effectively with clish. The shift from a rule-based CLI to a database-centric one is the biggest mental hurdle.

I'd add that the `add object` approach becomes crucial for automation. If you're scripting any kind of deployment or change, you have to create the object first before you can reference it in a policy command. Trying to shortcut that will just lead to errors.

Your tip on `show configuration full` is a good one. For anyone else reading, it's also worth remembering that `show configuration full` can be piped to a file. It's not pretty, but having that text file to search through offline can sometimes be easier than navigating the live CLI menus when you're looking for something specific.

You're absolutely right about scripting. The object-first approach is key, and once you embrace it, you can actually build some pretty reliable automation. It forces you to think declaratively, which is good practice.

One caveat I'd add: watch out for state. If your script runs `add object` for something that already exists, it'll error and stop. I've found wrapping those calls in simple conditionals (checking via `show object` first) saves a lot of headache in longer scripts. It adds lines, but makes the script idempotent, which is a lifesaver.

The offline search trick with `show configuration full > file.txt` is golden for debugging those scripts, too. You can grep for the object names you're trying to manipulate.

That's a key observation about the multi-step process. It's the exact reason why, for quick changes, I often find it faster to SSH to the box, use the `expert` mode to drop into bash, and edit a config file directly for things like interface settings or routes. Clish really forces you through the management server's workflow, even for local appliance config that has nothing to do with policy.

So for me, the CLI is three tools: clish for managed objects and policy, bash for the appliance itself, and SmartConsole for everything else. Trying to use clish for the wrong job is where the frustration really builds.

You're fighting the design. Clish isn't a config CLI, it's a database query tool for the management layer.

>creating a simple access rule feels like you need to pre-define objects

That's the security model. It's a feature, not a bug. No magic strings. Everything is a defined, auditable object. It's annoying until you need to prove compliance or track a change.

The quicker you stop treating it like IOS, the less it hurts. Use bash for local appliance config, use clish only for managed policy.

That transition is a real shock to the system, isn't it? You've nailed the core issue: it's a completely different philosophy.

>the whole philosophy feels opposite

That's because it is. Sophos XG's CLI is for configuring a box. Check Point's clish is for querying and manipulating a centralized security database. Your "simple running config" is a policy built from hundreds of database objects, not a flat file on the appliance. It's a tough mindset shift.

The multi-step object creation you're fighting is actually the key to making clish tolerable. Once you accept that you *must* `add object` first, you can start building little scripts for common tasks. It never gets as quick as a one-line deny, but it becomes predictable. For what it's worth, that object-centric rigidity is a big part of what auditors love during compliance reviews.

Right, the auditors love it. That's the sales pitch, isn't it? Meanwhile, my team has to spend twenty minutes creating objects just to test a quick hypothesis during an outage. That's not a security model, that's a tax on operational agility.

Compliance is a checkbox. Keeping the network running is the actual job. The object rigidity doesn't just slow you down, it actively discourages exploration and incremental changes. You're not building a policy, you're filing paperwork.

That's a perfect way to put it - the shock comes from realizing you're not just using a different syntax, you're interfacing with a whole different layer of abstraction. You're not touching config files, you're submitting database transactions.

The auditor love is real, but the operational cost is the hidden line item. It makes me wonder about the ROI of that rigidity during, say, a major incident. Is the audit trail worth the extra 10 minutes of downtime because I can't just drop a quick block rule? There's a real tension there between compliance theater and operational velocity.

Yeah, the automation script you can build from those `show object` checks is a total workflow game-changer. It turns a frustrating process into something you can actually trust to run unattended.

I keep a simple template script for that exact purpose - check, then add or set. It feels clunky at first, but that idempotency is what makes it usable long-term. The first time a script runs cleanly on the tenth try because the object already existed, you'll be glad you added those few extra lines.

Using bash for appliance config is smart, but you're bypassing the management system entirely. That config file you edit directly? It'll get overwritten on the next policy push from the management server. That's a ticket to a real headache when your change vanishes.