Configuring the Client Connectivity Policy

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.

Overview

Use the Client Connectivity Policy to apply the Device Postures and Checks that are performed by the Cato Cloud on devices for SDP 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.

For more about Device Posture Profiles and Device Checks, see Creating Device Posture Profiles and Device Checks.

 

 

Prerequisites

The Device Checks that are supported, are different for each OS. For more about the requirements for each check, see Creating Device Posture Profiles and Device Checks.

Preparing to Implement Client Connectivity Policy

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.

Supported Connectivity Policy Features

  • 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 SDP 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.

Configuring the Client Connectivity Policy and Settings

This section explains how to create the Client Connectivity Policy and add one or more profiles to each rule.

Working with the Ordered Client Connectivity Policy

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.

  • For rules with the Allow action, devices are allowed to connect to the network

  • For rules with the Block action, devices are blocked and can't connect to the network

Creating the Client Connectivity Policy

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:

  1. From the navigation menu, click Access > Client Connectivity Policy.

  2. Click New.

    The New Rule panel opens.

  3. Configure the scope of the rule:

    1. Define the Users/Groups, Confidence Level, Platforms, and Countries for this rule.
      For more information on Confidence Levels, see Remote Internet Security with One Time Authentication.

  4. 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. 

  5. Click Apply.

  6. Repeat steps 2-5 for each rule in the Client Connectivity policy.

  7. Enable the Client Connectivity Policy and then click Save.

    The slider toggle.png is green when the rule is enabled, and gray when the rule is disabled.

Sample Client Connectivity Policy

This section shows an example of a Client Connectivity Policy and how the rules are applied.

ClientConnectivity Policy.png
  1. The scope of rule 1 is the RnD groups for Africa and Europe with Windows devices.

    • When these SDP users try to connect to the Cato Cloud, they are only allowed to connect if they meet the requirements of the RnD Africa profile or the RnD Europe profile.

      Otherwise, the engine checks the user and device for the rule 2.

  2. 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 SDP 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.

  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.

SDP User Experience with Device Posture

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 shows an error message to the user. This is an example of the error message:

DevicePosture_ClientError.png

Click Details to show the specific requirements that the device doesn't meet. An event is also generated that shows the same details.

SDP User Experience with Unsupported OS Versions

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 SDP user, and the Client continuously tries to connect to the encrypted tunnel

  • macOS, iOS, Android, and Linux - SDP users are shown a message that says this device is blocked from the network (for example, connecting from this OS is forbidden)

Understanding Events for the Client Connectivity Policy

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.

Was this article helpful?

4 out of 5 found this helpful

11 comments

  • Comment author
    David Heyman

    has this feature been released to GA?  I do not see it in our console under the new management application as described.   

  • Comment author
    Yaakov Simon

    David,

    This feature will be available for GA starting from March 13th, 2022.

    Thanks,

    Yaakov

  • Comment author
    Yaakov Simon

    Jørn-Morten, 

    We are expanding the functionality of this feature, including adding support for additional Client OS.

    Thanks,

    Yaakov

  • Comment author
    Matthew Sutton

    What are the details regarding the statement -  We recommend that you do not enable Never-Off connectivity with Real-Time Checks    Thanks!

  • Comment author
    Michael Beattie

    Can this prevent devices connecting from sites behind a socket and apply to certain vlans only?

     

  • Comment author
    Yaakov Simon

    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!

  • Comment author
    Yaakov Simon

    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.

  • Comment author
    Michael Beattie
    • Edited

    Thanks Yaakov, are there any plans to have device posture requirements when behind a socket?

  • Comment author
    Yaakov Simon

    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.

  • Comment author
    CR Krishna Kumar

    Looks like  this document is outdated after the ‘Remote Internet Security with One Time Authentication’ was introduced. 

  • Comment author
    Michael Goldberg

    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. 

     

Add your comment