Introduction

This page provides details about settings and overall admin procedures for Cyolo Connect.

See also:

• Cyolo Connect - Overview
• Cyolo Connect - Device Management
• Cyolo Connect - Secure Web Gateway
• Cyolo Connect - Creating Device Policies
• Cyolo Connect - Troubleshooting & Helpful Information

Device Settings

You can find the Cyolo Connect settings under the Devices menu on the Admin Portal.

Regardless of the settings above, on Windows OS, Cyolo Connect runs automatically when
Windows starts - if installed with Windows Installer File (*.msi). On macOS it doesn’t.

1. If users' connectivity is restricted when they are signed into the Cyolo tenant, uncheck the
   'Apply restrictions to signed-in users' option in the device policy.
2. If the Captive Portal is allowed, and the browser doesn’t open automatically on Windows
   devices, list www.msftncsi.com in the allowed networks of the device policy (see more details on Microsoft documentation).
3. The policy is stored in a file called device_restrictions/policy.json, which is accessible only to
   administrators. This file contains all the necessary rules and exceptions for the kill-switch functionality. The file is stored in the directory where the Cyolo Connect Agent daemon executes from, with different locations for each operating system:

• Windows: C:\Program Data\Cyolo\Connect\device_restrictions\policy.json
• macOS: /Library/Application Support/cyolo/connect/device_restrictions/policy.json
• Linux: /usr/local/share/cyolo/connect/device_restrictions/policy.json

The file is obtained from the IDAC each time there is a poll for policy. This polling occurs
whenever the user first connects and every five minutes. If the policy file is deleted or corrupted, the kill-switch is disabled. The policy is obtained from the following api: https://agents.tenant-suffix/v1/device_policies/me.

4. Here is an example of the file:

{
"network_indicator":null,
"when_indicator_available":null,
"when_indicator_unavailable":
{
"allowed_networks":["website.com","192.168.5.10"],
"apply_kill_switch_when_connected":false,
"connectivity_mode":"restricted"
},
"allow_captive_portal":false
}

Constants

The following is a list of addresses and ports that Cyolo Connect always permits (not
configurable by the admin):

• DNS connectivity (TCP/UDP 53, UDP 5353, UDP/TCP 853)
• DHCP connectivity (UDP 67-68 and UDP 546-547)
• Loopback connectivity
• IPv4 broadcast (255.255.255.255)
• IPv4 multicast (224.0.0.0/4)
• IPv6 multicast (ff00::/8)
• The ZTNA tenant host
• bugsnag.com
• captive portal detection hosts mentioned above (if captive portal is allowed)

DNS

All domain names are resolved by both the device DNS (e.g., the Service Provider DNS) and the
IDAC DNS.

Apps configured with domain names use the address returned from the IDAC DNS.
For other domain names, the device DNS is used unless the domain is specifically configured on a Cyolo site.

To add domain suffixes to the Cyolo Connect use the /V1/search_domain end point
(GET/PUT/DELETE). Here is an example to create a new search domain:

PUT /v1/search_domain
{
"suffix": "google.com"
}

Resolution of FQDNs and Routing Mechanisms

Cyolo Connect handles FQDN and routing through the following processes:

1. Polling for Policy Changes: Cyolo Connect polls the IDAC for policy changes every 5
   minutes. During this polling, it retrieves two types of routes:

• Static Routes: Examples include routes like 10.10.0.0/16 , 11.11.11.11/32 , etc. These
  routes are applied directly as operating system routes by the Cyolo Connect agent.
• Dynamic Routes: These are domain names such as baz.com , bar.foo.com , etc. For these
  dynamic routes, the agent intercepts DNS requests and routes them on-demand, hence the term "dynamic."

2. Handling Wildcards and Specific Domains:

• Currently, Cyolo Connect does not support a wildcard syntax like *.foo.com . Instead,
  configuring foo.com is equivalent to specifying *.foo.com . There is already a feature request in place to introduce proper wildcard syntax support.

3. Legacy Handling of Single Label Names:

• Single label names, such as foo or server1 , are resolved in a legacy manner. The IDAC
  resolves these names and returns them as static routes. This method is not as efficient and can be prone to DNS resolution subtleties.

Benefits of Defining *.bar.com vs. foo.bar.com :

• By defining *.bar.com , all subdomains of bar.com (e.g., foo.bar.com , baz.bar.com ) are
  covered, ensuring comprehensive routing and access control without needing to specify each subdomain individually. This approach simplifies configuration and reduces the likelihood of missing necessary subdomains.
• Defining foo.bar.com only covers that specific subdomain, which may require additional
  entries for other subdomains, leading to more complex configurations and potential gaps in routing.

Logs

1. Users can download the Cyolo Connect log file from the Cyolo Connect menu ('Export
   System Logs').
2. In Windows, Cyolo Connect issues are logged in the event viewer under Application Logs.
3. In Linux, events are reported to SYSLog and can be streamed using the Journalctl tool
   (journalctl | grep -i cyolo).
4. In MacOS, the logs are located here in /usr/local/var/log/Cyolo.out.log and
   /usr/local/var/log/Cyolo.err.log.
5. Every time the user downloads Cyolo Connect, an event ID appears in the Admin Console’s
   activity log.

Implementation Details

Windows

• Backend: Windows Filtering Platform (WFP)
• Functionality: a sublayer named io.cyolo.killswitch ensures that all outbound network traffic
  is blocked when the Cyolo Connect Agent is not connected, unless specified in the exceptions. As this is not the “main” sublayer that is used by the windows firewall, the rules created by the kill-switch will not show up in tools such as wf.msc an administrator can view and edit those rules using tools such as WFPExplorer.

macOS

• Backend Technology: BSD Packet Filter (pf)
• Functionality: A policy file name /etc/io.cyolo.killswitch.conf contains rules that block all
  outbound network traffic when the Cyolo Connect Agent is not connected, with specified exceptions. The pf firewall on macOS enforces these rules to ensure network security. Additional rules that are added at runtime are stored within a table called outbound_exceptions an administrator may view and edit those rules using the pf tool.

Linux

• Backend Technology: iptables
• Functionality: a chain called io.cyolo.killswitch is created in the filter table and set as the
  default action of the OUTBOUND chain. an administrator may view and edit those rules using the iptables tool.

Captive Portal

In restricted mode, profiles specify whether temporary access to detected captive portals is
allowed on the device. When enabled, access is granted until the user establishes internet connectivity.

Known captive portal detection hosts are automatically whitelisted:

The underlying network is monitored for changes such as changing the default route or
adding/removing a uni-cast IP address from one of the physical network interface - in the case that a network change is detected, the following actions take place:

• For the first 15 seconds in the new network, all outbound TCP is permitted
• The agent starts polling for access to captive.cyolo.io:80 every second
• In the case that it sees a 204 response, TCP connectivity is restricted again
• In the case that it sees something else, a captive portal is assumed to be present in the
  network and TCP connectivity is left permitted.
• Once captive.cyolo.io returns a 204, TCP connectivity will be restricted again

Upon user login to the Cyolo tenant, Cyolo Connect pulls the profile configuration and applies
it to the device. Configuration updates occur every 5 minutes when the device is connected to the tenant. Login and resume also trigger the configuration pulling.