I've been conducting an extensive evaluation of Cato SASE over the past six months, focusing specifically on its performance as a transit layer for modern, stateful application traffic. A persistent and operationally significant issue has emerged with applications relying on long-lived WebSocket connections, such as collaborative document editors (e.g., Figma, Miro), real-time dashboards (e.g., Datadog Live Tail, Grafana), and certain DevOps tools (e.g., GitHub Codespaces terminal).
The core symptom is premature connection termination or persistent packet loss occurring at seemingly random intervals, typically between 90 and 180 seconds after establishment. This manifests not as a clean TCP reset, but often as a silent drop where the application layer eventually times out. My team's packet captures at the client and server ends (outside the Cato tunnel) show healthy TCP streams, indicating the issue is isolated to Cato's packet processing path.
Our current environment and testing methodology is as follows:
* **Cato Client:** Version 5.9.0 (also observed in 5.8.x series) on standardized developer endpoints.
* **PoC Test Application:** A simple Node.js WebSocket echo server hosted on AWS (us-east-1) and a corresponding client, both logging precise timestamps and sequence numbers.
* **Control Tests:** Direct internet connectivity and a competing vendor's SASE solution show zero interruptions over 24-hour stress tests.
* **Cato Configuration:** We've experimented with multiple relevant policy adjustments:
* Disabling all "Threat Prevention" and "Data Loss Prevention" features for the test policy.
* Setting "Application Timeout" to the maximum value (86400 seconds).
* Explicitly classifying the traffic under "Collaborative Apps" and "Remote Access" categories.
* Testing with both TLS Inspection enabled and disabled (the issue occurs in both states, though the failure mode differs slightly).
The data suggests Cato's flow state table or its intermediate packet gateways are aggressively pruning or resetting connections it deems inactive at the *application* layer, even though the TCP keep-alives (or WebSocket pings/pongs) are functioning correctly. This points to an inspection heuristic that doesn't adequately account for low-bandwidth, persistent stateful protocols.
My questions for the community are:
* Has anyone replicated this issue and performed a root cause analysis, perhaps with traceroute or Cato socket data during a failure event?
* Are there undocumented CLI parameters or registry tweaks for the Cato Client to influence TCP state tracking or timeouts?
* Beyond the global "Application Timeout," is there a specific, separate timeout for "stateful connection tracking" that is configurable via API but not in the UI?
* Has Cato Engineering provided any official guidance or bug acknowledgments for WebSocket-heavy SaaS applications like Lucidchart or Airtable?
The operational impact is non-trivial, requiring developers to implement complex reconnection logic and state synchronization for applications that previously functioned reliably. I am compiling a formal benchmark comparing packet loss and mean time between failure (MTBF) for WebSocket connections across several SASE providers; preliminary data places Cato as a significant outlier. Any shared experiences or diagnostic data would be valuable for this analysis.