Everyone's hyping Cato as the all-in-one SASE magic bullet. But if your setup is a classic small office—think under 50 users, a local file server for CAD files or QuickBooks, maybe a legacy app that needs on-prem resources—you're going to have a bad time.
The core issue: Cato is built for a cloud-first, any-to-any model. It wants all your traffic to go through its PoPs. That creates two major headaches for a local-server setup:
* **Chatty protocol penalty.** SMB, NFS, even some SQL traffic between a user and a server in the same physical office now takes a ridiculous detour out to a Cato PoP and back. Latency goes from <1ms to 20ms+. Try working on a large file over the network; it's painfully sluggish. Their "direct internet access" and "optimized routing" don't solve this for server traffic unless you start carving out exceptions, which defeats the purpose.
* **Cost for no benefit.** You're paying per Mbps for the tunnel from your office to Cato. Why pay to backhaul local traffic that never needed to leave the building? It's wasted throughput and adds a pointless bottleneck.
The support answer is usually "use a local breakout policy." Fine, but then:
- Your file server traffic isn't inspected by their security stack. So much for "all-in-one."
- You now have a complex policy set managing what goes local vs. to Cato.
- You still need a traditional firewall for that local segment.
You're left managing two networks: the Cato overlay for internet/cloud stuff, and your old local LAN for servers. It's brittle, more complex than when you started, and you're paying a premium for it.
If your world is 90% SaaS apps, Cato makes sense. If you still have core on-prem resources, you're better off with a good next-gen firewall and a straightforward SD-WAN for branch connectivity. Don't let the buzzwords sell you a worse, more expensive architecture.
Integration is not a project, it's a lifestyle.