Explore the Community
Cato Cloud
Cato and SASE discussions and best practices.
API
API questions-and-answers, discussions, and best practices.
Recent Content
What is the difference between App Control Rule "Allow + Tracking: Event Enable" and "Monitor"?
In the *App & Data Inline* -> *Application Control Policy*, we have configured the rule as follows: - **Action: Allow** - **Tracking: Event** (Enabled) However, under this configuration, **no events are shown in the Events screen**. Is this the expected behavior? We are confused because there is also an **Action: Monitor** option, yet "Allow" can also be configured with Tracking enabled or disabled. Could you clarify the functional difference between these two actions and how they affect event logging?
Use Case- Bypass internal application access through CATO when in office
I have been using Netskope where there is feature of split tunneling wherein when it detects that you are in office network then you can disable remote access and the traffic to internal application will be routed using your office MPLS/ILL thus only internet traffic going to CATO but when same users are working from home then both remote access as well as internet traffic goes via Netskope. Now with CATO, there is no option with me to exclude traffic going to CATO POP except IP ranges but I want the same experience that when users is in office, only internet traffic goes through CATO and not private access. I want this spliting done through CATO SDP client as I dont have any site license.
Additional South Africa POP
Hi all Does anyone know when a POP will be established in Cape Town? The reason I ask is because quite a lot of times, especially in our 100% remote org working from home, upstream traffic between CPT and JHB is very slow or has issues causing degraded performance. In some cases there's a 50-60Mbps difference between local breakout (without Cato) and the Cato breakout in JHB.
Simplifying TLS Inspection with Cato's ML-driven Wizard
You made the first step, this is THE place to learn more, get your questions answered and share your experiences with other Cato customers. Our TLS Wizard is designed with a clear purpose: intelligently determine which traffic to bypass and which to inspect, giving you immediate visibility into the most-commonly used applications and websites in your network. We leverage real-world customer traffic insights to identify which traffic works well with TLS inspection and which might be problematic. What Traffic Should Not Be Inspected? Four types of traffic should typically bypass TLS inspection: Certificate Pinned Applications - These applications require specific certificates and will fail when inspected. Cato automatically bypasses known problematic OS, applications and URLs using our default bypass rule — without requiring the Wizard! Embedded OS Devices - IoT devices like printers, cameras, and smart TVs don't support certificate installation and won't work with TLS inspection. Sensitive Categories - While Cato never stores payload data, bypassing health, medical, and financial categories helps ensure privacy and compliance. Traffic originating from Guest networks (or other devices that do not have the Cato certificate installed) – typically it’s not possible to inspect traffic from guest devices as they will not have the Cato certificate installed and will therefore generate an error if inspected. The TLS Wizard adds bypass rules for embedded OS and sensitive categories automatically. The bypass of guest networks will need to be created manually as this is not a generic rule that applies to all customers. What Traffic Should Be Inspected? The Wizard recommends inspecting these five categories: General, Business Information, Computers and Technology categories Popular cloud applications Cato-recommended domains (approximately 6,000 domains verified to work with TLS inspection) Malicious and suspicious categories Uncategorized and undefined categories Remember, these are suggestions that you can customise during setup. You might want to start by testing with specific users or groups. Best Practice for the Default Inspection rule To prevent unexpected traffic inspection, we recommend configuring your default TLS inspection rule to bypass. After running the Wizard, you'll be: Bypassing known problematic sources and destinations Inspecting known-good, high-value destinations Bypassing everything else by default You can customise and expand upon this foundation later, we recommend adding the bypass for the guest networks in the appropriate section of the TLS inspection policy as a starting point. See the TLS Wizard in Action: Watch the demonstration - https://www.youtube.com/watch?v=zYVoxHA09NY&t=14s Visit our Knowledge base article Have questions? Use the "comment" option at the bottom of this page. We're monitoring closely and ready to assist you on your journey
addSocketSite Location lookup incomplete
Trying to add sites to tenant via API Using addSocketSite in Postman. Fails, reporting: {"errors":[{"message":"timezone [US/Pacific] is unknown","path":["site","addSocketSite","input","siteLocation","timezone"]}],"data":{"site":{"addSocketSite":null}}} Inspecting the results of the lookup, I can see that UA has three timezones When you lookup US there is only one timezone. If I am importing 15 sites only the sites in Mountain timezone succeed. Is this a production tool or method?Split Tunnel basis FQDN/Domain
I am facing some issue wherein I am not able to browse some government site. There was an article on the same as well. As of now , I have configured split tunnel basis exclude IP and I have excluded IP address of one of the website of Government but this is not going to work as I have multiple websites of government which is not opening. Why there is no option to bypass or split tunnel basis FQDN or domain then I can exclude traffic for Government sites as it becomes a task for doing split tunnel basis individual IP address. Is it on road map as well or not?
