about Always-on Issue
On iOS devices, client certificate authentication and “Always-on” VPN configuration" is created with one configuration profile and distributed through MDM. The Cato Client app is also purchased thro...
Forum Discussion
michaelsaw
Cato Employee
Cato EmployeeHi Shiva-SBI,
Noted that MDM is in place.
You mentioned: "The problem with this is that users can manually turn off the VPN switch."
I was reviewing the KB on Always-on with SSO: https://support.catonetworks.com/hc/en-us/articles/4417643184529-Protecting-Users-with-Always-On-Security
Can we check what is the version of Cato Client installed?
Is there a support ticket submitted with our Support team to check further?
Thank you.
Hi michaelsaw,
Thank you for your reply.
Yes, a ticket has been opened with support and it has progressed to Tier 3. I posted here to see if there are any admins or partners experiencing the same issue and if anyone has been able to resolve it.
Always-on is set correctly according to the procedure in the Learning Center, and the user's Cato Client is 5.4 or 5.5.
Distributing Device Certificates to macOS and iOS Devices with Jamf
The point of the problem is that Cato Client adds an on-demand VPN configuration automatically after authentication is complete. (It was not a profile.)
This results in two VPN configurations, one added from MDM and one added by Cato Client, and by the user switching between them or deleting the on-demand VPN configuration, unmanaged Internet access becomes possible.Thank you!!
shiva-SBI
These are the facts that are currently known. Cato is also aware of these issues.
When using the Cato Client for SDP users on iOS, Always-on does not work as we would like.
A VPN configuration ”Cato Networks VPN” that the Cato Client creates locally supports all Cato communication, but this can be manually deleted by the user, and is a means to ensure that Always-on is bypassed.
In addition, in the case of using a client certificate as device authorization for SDP users, there are two profiles: a client certificate and VPN configuration profile distributed by MDM, and a VPN configuration created by Cato Client. Users can simply switch between the two available VPN profiles to disconnect the VPN and bypass Always-on communication.
This current specification could lead to serious security incidents.
Based on current knowledge, there is no workaround that can avoid this issue. The current device authorization using client certificates is not practical for implementation. At least for orgs that use MDM, it is best practice to distribute the device compliance key using AppConfig and the on-demand VPN configuration created locally by Cato Client from MDM, but to do this, Cato needs to prepare an MDM client such as Cato Client for EMM.
I think it would be fine to require MDM for Always-on use with SDP Cato Client.
I hope this issue can be resolved soon.
Thank you.
shiva-SBI
