Guide: Setting up site-to-site failover with dual ISPs using Cato.

Having recently completed a multi-region deployment for a financial services client with stringent uptime SLAs, I was tasked with architecting a resilient site-to-site topology leveraging Cato Networks' SDP. The core requirement was seamless failover between dual, diverse Internet Service Providers at each physical location, a scenario where traditional VPN solutions often introduce complex BGP or routing protocol dependencies. Cato's architecture, which abstracts the underlying transport layer, presents a unique paradigm for achieving this.

The fundamental principle is that a Cato Socket (or a hosted Cato PoP for cloud sites) can establish multiple WAN links. Failover is handled at the Socket level, not within the Cato Management Application itself. The configuration is a blend of Cato's web console and on-premise Socket configuration.

**Primary Configuration Steps:**

* **Socket WAN Configuration:** Each physical Socket must be configured with at least two WAN interfaces, each connected to a distinct ISP. This is performed locally on the Socket's management interface (typically ` https://:8443`). You will define primary and secondary links, with health check targets (e.g., `8.8.8.8` and `1.1.1.1`) to determine link viability.
```bash
# This is a conceptual representation of the logic, not direct CLI.
WAN1:
IP: 203.0.113.10/24
Gateway: 203.0.113.1
Health Check: 8.8.8.8
Priority: Primary
WAN2:
IP: 198.51.100.20/24
Gateway: 198.51.100.1
Health Check: 1.1.1.1
Priority: Secondary
```

* **Site Definition in Cato Management Application:** In the Cato cloud, you define a *Site* for each physical location. Crucially, you add *both* WAN IP addresses (the public IPs assigned by each ISP) to the same Site object. Cato's PoPs will then treat these as potential endpoints for the same logical site.

* **Site-to-Site Policy:** You then create a standard site-to-site security policy between the relevant sites. The policy is agnostic to which specific WAN link is active; it governs traffic between the site identities. The failover mechanism is entirely transparent to the policy layer.

**Critical Observations and Pitfalls:**

* **Stateful Failover:** The Socket maintains TCP/UDP session state across the failover event for connections that are proxied through Cato's PoPs. However, for optimized (peer-to-peer) tunnels that form directly between Sockets, a WAN failover will cause those specific tunnels to re-establish, potentially dropping packets during the convergence period (typically sub-30 seconds).
* **Asymmetric Routing:** Ensure local firewall policies on the Socket's LAN interface allow return traffic from both ISP subnets. A common mistake is restricting outbound traffic to only the primary WAN subnet, which will break failover.
* **Testing:** Do not simply unplug a cable. Use the Socket's local interface to administratively disable a WAN link to simulate a clean failure. Monitor the Cato Analytics dashboard for "Socket WAN Link" events to validate failover and convergence times.

This design effectively outsources the complexity of path selection and health monitoring to the Cato Socket, while maintaining a single, consistent security policy. It is superior to DIY IPSec solutions for this use case, though you must be aware of the behavioral differences between proxied and optimized traffic flows during a failover event.

--from the trenches