Alright, let's see if we can pull this one out of the swamp. I'm not a Cato admin by trade, but I've been dragged into enough network-layer troubleshooting to know that when an application like Salesforce starts demanding re-auth every five minutes, it's usually because something in the middle is getting too clever for its own good. The security team loves Cato, but the helpdesk tickets are piling up.
First, let's rule out the obvious Salesforce-side config. It's rarely that. The pattern screams something is either terminating connections prematurely or mangling headers. With Cato sitting as your SASE layer, you need to look at a few specific policies.
* **Check your Cato Access Rule for Salesforce.** Specifically, look for any "Application Control" or "Threat Prevention" profiles that might be doing Deep Packet Inspection (DPI) on HTTPS traffic. If it's trying to inspect the encrypted traffic to `login.salesforce.com` or your specific instance, and it doesn't handle the persistent sessions correctly, it'll force re-authentication. You might need to create an exception.
* **Review the Idle Timeout on the relevant Socket.** In the Cato management console, navigate to your account's network settings. Find the socket (either for the site or the users) that's handling this traffic. There's usually an **Idle Timeout** setting. If this is set too low (like 5-10 minutes), it will kill the TCP session after that period of inactivity, which Salesforce interprets as a broken connection. Bump this up to 30 or 60 minutes as a test. This is a classic culprit.
* **Verify there's no SSL decryption/inspection for that domain.** Even if you think it's off, go check. A misguided "default" profile can snag things.
If you can, share the sanitized config of the Access Rule and the Socket settings. I'm less interested in screenshots and more in the actual policy logic. Something like this:
```
Access Rule:
Source: Corporate_Users
Destination: Salesforce_IP_Range
Service: HTTPS
Action: Allow
Application Control: Enabled (Profile: "Default-Business-Apps")
Threat Prevention: Enabled (Profile: "Default-Strict")
Socket (for your site):
Idle Timeout: 300 seconds
TCP Keep-Alive: Enabled
```
That `300 seconds` idle timeout next to an "Allow" rule with inspection profiles is usually the murder weapon. Turn off the Application and Threat control for that rule as a test, or crank the idle timeout way up, and see if the prompts stop. Then you can work backwards.
Also, get your networking folks to pull the Cato audit logs for a user experiencing this. Filter for connection closures and terminations on the Salesforce destination. The reason codes can be illuminating.
-- old salt
You're on the right track, but I'd tighten that focus even more. It's almost never the Idle Timeout on the socket itself. The issue is specifically the **Application Control** or **Threat Prevention** profile inspecting the HTTPS session.
When Cato does TLS inspection on something like Salesforce, it essentially becomes a man-in-the-middle. If its inspection engine doesn't perfectly replicate the session keep-alives or mishandles certain cookies, Salesforce sees a new connection from a new client IP (Cato's inspection engine) every time. That's your five-minute re-auth right there.
Create an exception rule for the specific Salesforce domains (`*.salesforce.com`, `*.force.com`) to bypass TLS inspection. Just set the Action to "Allow" without any security profiles attached. The security team will squawk, but you tell them the alternative is users writing down passwords on sticky notes.