Connecting to the Cato SASE Cloud — Branch, Datacenter, Cloud & Remote Users

① One cloud, four on-ramps — and the nearest PoP

The single idea to hold: in Cato, all the security and routing intelligence lives in the SASE Cloud, so deploying Cato is really just deciding how each edge connects to it. Whatever the edge — a branch, a cloud datacenter, a remote laptop, or a third-party site — it builds an encrypted connection to the nearest Cato PoP and from then on shares the same single policy and the same security stack.

There are four main on-ramps. A physical site uses a Cato Socket (the zero-touch SD-WAN device). A cloud datacenter in AWS, Azure or GCP uses a vSocket or a native cloud IPsec / cross-connect. A mobile or remote user uses the Cato Client agent or clientless browser access for ZTNA. And for quick onboarding or a partner site you can use a plain IPsec tunnel from an existing firewall. The connection method only changes the on-ramp and how much last-mile optimization you get — not what happens once traffic reaches the PoP.

② Physical sites with the Socket — and the third-party IPsec trade-off

For a real site you can ship hardware to, the on-ramp is the Cato Socket. Best practice is to deploy it as an HA pair with multiple WAN links (fiber, broadband, cable plus 4G/5G/LTE) run active/active. This is the only on-ramp that gives full last-mile SD-WAN optimization: active/active link aggregation, application-aware path selection and packet-loss mitigation, all measured on the local links before traffic ever hits the PoP.

When to reach for plain IPsec instead

Sometimes you need connectivity fast — a partner site, an acquisition, or interim coverage before a Socket arrives. For that you can build a plain IPsec tunnel from an existing edge firewall into a PoP, with no Socket at all. It is quick to stand up and the site still gets the full Cato security stack at the PoP. The trade-off: with no Socket you lose some last-mile SD-WAN optimization — there is no active/active aggregation and no last-mile packet-loss mitigation. Use IPsec for what it is good at, and put a Socket where the last mile actually matters.

③ Cloud datacenters and remote users

Cloud workloads need an on-ramp too — a common miss is securing every branch but leaving the AWS/Azure/GCP estate connecting some other way. The fix is to drop a vSocket (a virtual Socket instance) inside the VPC/VNet, or use a native cloud IPsec tunnel or cross-connect. Now cloud-bound and cloud-origin traffic is secured and optimized by Cato, exactly like a branch — the vSocket connects cloud workloads to the nearest PoP the same way a physical Socket fronts a site.

For mobile and remote users there are two on-ramps. The Cato Client is an agent on the laptop or phone that tunnels the device to the nearest PoP and applies the full policy. Clientless browser access gives ZTNA to specific web apps with no agent at all — ideal for contractors, BYOD, or any device you cannot install software on. Same PoP, same policy; you simply pick agent or agentless based on the device.

④ Phased migration, sizing and the pitfalls

You do not big-bang a SASE rollout. The model is a gradual SASE transformation: run Cato alongside your existing MPLS and internet, cut over site by site, prove each one, and then decommission the MPLS circuits, VPN concentrators and standalone firewalls over time. Nothing forces a flag-day, and you can roll back a single site if needed.

Sizing and the classic misses

Sizing is straightforward: choose the Socket model by the site's throughput, deploy an HA pair at critical sites, and let Cato pick the nearest PoP automatically — bandwidth licensing follows your plan. The pitfalls everyone hits: going IPsec-only everywhere (losing the Socket's last-mile SD-WAN); skipping HA at a critical site; attempting a big-bang cutover instead of a phased one; and forgetting cloud workloads need their own on-ramp (a vSocket or connector), not just the branches.