This article discusses how you can use the Client Connectivity Policy as part of implementing and enforcing Zero Trust Network Access (ZTNA) in your Cato account.
Use the Client Connectivity Policy to apply the Device Postures and Checks that are performed by the Cato Cloud on devices for users. If the device fails to comply with the policy that was set for the profile, then the user can't connect to the Cato Cloud.
For example, you can only allow remote users to access internal resources when they are compliant with the Device Posture policies. This can improve your confidence in the devices that are connected to your internal resources.
You can also use the Client Connectivity Policy to provide users with secured remote Internet access after one time authentication. For more information, see Remote Internet Security with One Time Authentication.
Device Checks are supported for Windows and macOS Clients. For more information about the requirements for each check, see Creating Device Posture Profiles and Device Checks.
The goal of the policy is to only trust devices that match the policy. Therefore, define rules that block all non-trusted devices so they are NOT allowed to connect to the network.
Before you enable the Client Connectivity Policy, make sure that you decide what the behavior is for users with unsupported Clients and operating systems. Do you want to allow these users to connect to your account? For example, users with Linux Clients or Windows Client v4.7 and earlier.
-
Configuring checks for a variety of Anti-Malware and endpoint Firewall vendors, to make sure that the relevant software is installed and running to allow remote access with the Client.
-
We recommend that you do not enable Always-On connectivity with Real-Time Checks, because if a device fails to meet the policy requirements, the Client may abruptly disconnect from the network. This can provide a bad user experience for the user.
You can review the list of supported vendors and versions for Real-Time Checks here.
-
The Connectivity Policy is an ordered policy, therefore you can add users to multiple profiles or rules. However, the first matching rule is applied to the user.
This section explains how to create the Client Connectivity Policy and add one or more profiles to each rule.
If a device that matched the User/Groups, Platforms, Countries, and Device Posture Profile for a rule, then the rule action is applied to the device.
The Client Connectivity Policy is an ordered rulebase, and each rule scope of users that rule applies to, including: geo-location (Countries), and device OS. When users or groups match the rule, the Cato Cloud manages the connections as follows:
-
When they meet the Device Profile requirements for a rule, they are allowed to connect to your account.
-
When they don't meet the Device Profile requirements for a rule, the Cato Cloud continues to inspect the posture according to the lower priority rules in the policy.
-
The device for any user or group that doesn't match any rule, is blocked by the final implicit rule of the policy (ANY ANY block).
To create the rules for the Client Connectivity policy:
-
From the navigation menu, click Access > Client Connectivity Policy.
-
Click New.
The New Rule panel opens.
-
Configure the scope of the rule:
-
Define the Users/Groups, Confidence Level,Platforms, and Countries for this rule.
-
-
Expand the Device Posture Profiles section, and select the profiles for this rule.
Note: Selecting Any Device Posture Profile means no Device Posture Profiles are included in the rule.
- Select the Action for the rule. For more information on available actions, see Remote Internet Security with One Time Authentication.
-
Click Apply.
-
Repeat steps 2-5 for each rule in the Client Connectivity policy.
-
Enable the Client Connectivity Policy and then click Save.
The slider
is green when the rule is enabled, and gray when the rule is disabled.
This section shows an example of a Client Connectivity Policy and how the rules are applied.
-
The scope of rule 1 is the RnD groups for Africa and Europe with Windows devices.
-
The scope of rule 2 is the RnD groups for Africa and Europe with Windows devices that did NOT meet the Device Posture Profile requirements in rule 1.
-
When these users try to connect to the Cato Cloud, they match the Device Posture Profile Any, and are blocked. They can't connect to the Cato Cloud.
-
Rule 2 does not apply to users that are not members of the the RnD groups for Africa and Europe, and these users continue with rule 3.
-
-
The scope of rule 3 is any user or groups with a Windows device.
When the users try to connect to the Cato Cloud, they are only allowed to connect if they meet the requirements of the Sample profile.
Otherwise the users are blocked by the final implicit ANY ANY Block rule.
When devices match the Device Checks, they can connect to the Cato Cloud and the experience for the user is that the Client shows that it is Connected. This is the same user experience as when there is no Device Posture policy for the account.
When a device fails to match a Device Check, the Client does not connect to the Cato Cloud and the Client shows an error message to the user. If a device fails a period check, after the Client is connected, the Client disconnects and the same error message is displayed.
This is an example of the error message:
Click Details to show the specific requirements that the device doesn't meet. An event is also generated that shows the same details.
When you create a Client Connectivity policy for an OS, we strongly recommend that you make sure that all devices are upgraded to minimum supported Client version. For rules that don't allow access for earlier (unsupported) Client versions, this is the end-user experience:
-
Windows OS - no message is shown to the user, and the Client continuously tries to connect to the encrypted tunnel
-
macOS, iOS, Android, and Linux - users are shown a message that says this device is blocked from the network (for example, connecting from this OS is forbidden)
The Cato Management Application generates two types of events related to the Client Connectivity Policy:
-
Whenever users or User groups comply with the requirements of a Client Connectivity Policy rule and are allowed to connect to the network.
-
Whenever users or User groups are blocked from connecting to the network because they fail to meet the requirements of the Client Connectivity Policy.
The following table explains some of the event fields from an Allow action event:
|
Field |
Explanation |
|---|---|
|
Device Posture Profile |
The name of the Device Posture Profile the device complies with. |
|
Rule |
The name of the Client Connectivity Policy rule that allowed the device to connect. |
|
Authentication Method |
The authentication method used by the user to authenticate to the Client. |
The following table explains the different Connectivity events with the Block action and the reason that the connection was blocked.
|
Event Sub-Type |
Reason for Blocking |
Description of Event Message |
|---|---|---|
|
Client Connectivity Policy |
Device fails to meet the Device Check |
Shows the details of the Anti-Malware or Firewall installed on the device, and what is required for the Device Check. |
|
Client Connectivity Policy |
Unsupported Client |
The device is connecting using a Client OS or version that is not supported and the matching rule doesn't allow unsupported Client to connect. |
|
Client Connectivity Policy |
Device fails to match any rule |
The device did not match the scope of any rule in the Client Connectivity Policy. So, the connection was blocked by the final implicit rule. |
13 comments
has this feature been released to GA? I do not see it in our console under the new management application as described.
David,
This feature will be available for GA starting from March 13th, 2022.
Thanks,
Yaakov
Jørn-Morten,
We are expanding the functionality of this feature, including adding support for additional Client OS.
Thanks,
Yaakov
What are the details regarding the statement - We recommend that you do not enable Never-Off connectivity with Real-Time Checks Thanks!
Can this prevent devices connecting from sites behind a socket and apply to certain vlans only?
Matt - When Always-On connectivity is enabled for an SDP user with Real-Time Checks, if a device fails to meet the policy requirements, the Client may abruptly disconnect from the network. This can provide a bad user experience for the SDP user.
We updated the KB article with this information. Thanks!
Michael - VLANs are a networking feature, and the Client Connectivity policy is designed to work with the Remote Access policy for your account. So you can't create a policy that prevents devices connecting for specific VLANs for sites.
Thanks Yaakov, are there any plans to have device posture requirements when behind a socket?
Updated article for new rulebase logic for the Client Connectivity Policy.
For information about the previous logic and the new logic, see Understanding New Logic for Client Connectivity Policy.
Looks like this document is outdated after the ‘Remote Internet Security with One Time Authentication’ was introduced.
Hi CR Krishna Kumar,
Thanks for the feedback. Remote Internet Security with One Time Authentication is a feature implemented through the Client Connectivity Policy. You can read more about this feature here.
The above article explains how to manage device posture requirements using the Client Connectivity Policy.
Although they are both managed from the same page in the Cato Management Application, these two features address two different use cases and are therefore explained in two separate articles.
There seems to be new Actions available that are not described in this article?
Hi JM,
Those Actions are part of the Remote Internet Security with One Time Authentication feature and are documented here.
Please sign in to leave a comment.