We're evaluating a move to put our factory floor IoT gear (IP cameras, environmental sensors, PLCs) under Cato's SASE umbrella. The pitch is replacing a mess of VLANs and firewall rules with a zero-trust overlay. Sounds clean, but I'm skeptical about overhead and visibility.
Initial PoC shows the Cato socket works on x86 gateways, but half our sensors run on proprietary ARM chips. Their "any device" claim needs a hardware gateway, which adds a hop. We're now looking at:
* Latency baseline added by the Cato PoP for UDP streams (camera feeds).
* Whether sensor telemetry protocols (MQTT, Modbus TCP) survive the TLS encapsulation without choking.
* How the firewall policy actually handles non-HTTP/S traffic. Their UI is web/app centric.
Main questions for anyone running this in production:
* How are you handling multicast for device discovery? Did you have to implement unicast converters?
* What's the real-world throughput hit on a Cato-gatewayed subnet? Our specs show a 30% drop, which eats into camera quality.
* Any issues with Cato's DPI breaking legacy IoT protocols? Support says it's pass-through, but I don't trust it until I see packet captures.
If you've tried this, share your architecture and pain points. Logs and config snippets are worth more than marketing slides.
-shift
shift left or go home
Ran this last year for a client's warehouse telemetry. Your skepticism is warranted.
> How are you handling multicast for device discovery?
You'll need a unicast converter. Cato doesn't route multicast. We used a small Linux box on each subnet running `avahi` reflector for mDNS, proprietary discovery needed custom code.
The 30% throughput hit is real for video. We saw 25-35% loss on UDP streams to the Cato PoP, forcing lower bitrates. For MQTT and Modbus TCP, the TLS tunnel adds negligible overhead if your gateway has hardware crypto. The problem is DPA, not DPI. Their firewall will pass the traffic, but the analytics engine mislabels it, causing false positives in the threat log.
Don't trust support's "pass-through." Run your own captures from a mirrored port on the Cato gateway. We found Modbus TCP sessions being reset after 10 minutes of idle time due to an invisible TCP timeout setting. Had to open a ticket to get it changed globally.
You're adding a hop and a bottleneck for cleaner policy. For low-throughput sensors, it's fine. For cameras, you'll compromise.
Ship it right
Your point about the TCP timeout resetting Modbus sessions is critical, and it's a common pain point many overlook. We had a similar issue with a different SASE provider, not Cato, where BACnet/IP sessions were being torn down. The root cause was often the TCP keepalive or idle timeout settings on the virtual firewall appliance, which are tuned for web traffic and hidden from the admin console. The fix usually requires a support ticket, as you found, but it leaves you vulnerable to policy changes.
The throughput hit on UDP streams aligns with what I've measured. It's less about the crypto overhead and more about the additional bufferbloat and packet reordering introduced by the extra hop through the PoP. For camera feeds, you can sometimes mitigate it by adjusting the encoder's packetization and using a fixed bitrate instead of VBR, but that's just optimizing around the bottleneck.
The false positive threat logs for industrial protocols are a significant operational burden. Without native protocol decoding, the analytics engine treats all non-web traffic as a potential data exfiltration stream. We built a separate log filter to exclude known sensor IPs from certain alert categories, but it's a band-aid. Has your client considered using Cato's API to automatically suppress those false positives, or are they just manually reviewing the logs?
connected