Netskope client is an agent-based deployment method where a lightweight non-intrusive agent is installed on the endpoint. The Netskope client provides the most comprehensive coverage as they can be installed on managed devices to provide visibility and policy enforcement for devices that are both on-premises and remote (off network).
The Netskope client steers the traffic from the users’ device to the Netskope cloud based on certain rules and policies. HTTP(S) and non-HTTP(S) traffic is sent to Netskope gateway and based on traffic type, HTTP(S) traffic is forwarded to Netskope Proxy and non-HTTP(S) traffic is forwarded to Netskope Cloud Firewall. Netskope cloud performs policy enforcement, and the activity is displayed on the Netskope console in the cloud.
This article focuses on steering the non-HTTP(S) traffic to the Netskope Cloud Firewall.
A typical Netskope Cloud Firewall network diagram (with Netskope client) is as follows:
 |
Netskope Client reads the DNS query before sending it to Cloud Firewall in order to apply possible DNS Steering Bypasses based on the requested record. If the Netskope client cannot read the actual query inside the DNS packet (for instance if the DNS query is DNScrypt on UDP/TCP 53), the query is steered inside the tunnel without the possibility to perform DNS Steering Bypasses.
Netskope Client logs TCP-based traffic as Cloud Firewall tunneling entries at the info log level (the default) and the UDP-based traffic as Cloud Firewall tunneling entries at the debug log level.
Netskope Client (with Cloud Firewall) Supported Operating System
Netskope client (with cloud firewall) supports the following operating systems:
- Windows 10 or later
- Windows Server 2016 or later
- macOS Big Sur or later
- iOS 15 or later
If you have a older version of Windows or macOS, refer Netskope Client Dynamic Steering, Fall Back, and Fail Close Behavior.
Configure Netskope Client to Steer Non-HTTP(S) Traffic
To configure Netskope client to steer non-HTTP(S) traffic to Netskope Cloud Firewall, follow the steps below:
Set Traffic Steering to All Traffic
Netskope client needs to steer HTTP(S) as well as non-HTTP(S) traffic to the Netskope cloud. To set the traffic steering option, follow the steps below:
- Log in to the Netskope tenant UI.
- Navigate to Settings > Security Cloud Platform > Traffic Steering > Steering Configuration.
- Click the Default tenant config entry.
- On the top-right, click EDIT and set the Traffic Steering option to All Traffic.
- Click Save.
Create a Firewall App and Real-time Protection Policy
Then, you can create an App Definition, followed by a Real-time Protection policy. Click the following links to go to the respective procedure:
Configure Steering Exceptions
If you have a requirement for the Netskope client to bypass certain non-HTTP(S) applications, follow the steps below:
Note
- Ensure that you have already created a firewall application from the Settings > Security Cloud Platform > Traffic Steering > App Definition page.
- If you have created a firewall application using wildcards (for example, *.xyz.com), the Netskope client bypasses the subdomain entries only (i.e., mail.xyz.com, play.xyz.com), the root domain (i.e., xyz.com) continues to get steered to the Netskope gateway. To avoid this, ensure that you explicitly add the root domain in the App Definition page and include this application in the exception list.
- Log in to the Netskope tenant UI.
- Navigate to Settings > Security Cloud Platform > Traffic Steering > Steering Configuration.
- Click the Default tenant config entry.
- Under the Exceptions tab, click the New Exception drop-down list and select Application.
- Select the firewall application you created in the App Definition page and click Add.
When the Netskope client is in “All Traffic” mode or cloud firewall is enabled, the following traffic is bypassed by default:
- DNS IPv4 ( If the Steer DNS traffic option is not selected)
- DNS IPV6
- Non-HTTP(S) IPv6
Note
Netskope client blocks inbound TCP connections from sources that do not fall under the steering exceptions. For example, enabling cloud firewall client on a Windows virtual machine in Amazon Web Services loses Remote Desktop Protocol (RDP) connectivity from the internet. To have seamless connectivity, ensure that such inbound TCP connections are defined under the firewall steering exceptions list.
Deploy the Netskope Client
Documentation on various Netskope client deployment options can be found here.
As a workaround, you can do the following:
1. Enable the enableMacPerformance flag on the tenant that was introduced in the Client release 96.
2. Using alternate FTP applications like Cyberduck, MacOS FTP Client [ftp (GNU inetutils)] to perform file uploads.
Netskope Client Dynamic Steering, Fall Back, and Fail Close Behavior
This document outlines the various traffic steering types in the Netskope Client and how dynamic steering, fallback, and fail-close behaviors are managed, particularly differentiating based on the enablement of Flexible Dynamic Steering.
Event Management
Flows managed by NSproxy generate Transaction Events while flows managed by Cloud Firewall will generate Network Events.
Consider the following context:
- With HTTP-AD disabled, traffic to port 80 or 443 are sent to NSproxy directly.
- Other traffic for ports in Steering Configuration > Non-Standard Ports is also sent to NSproxy with the selected domain and port combination.
- This traffic was destined to 443 and it was sent to nsproxy.
- NSproxy respects cloud firewall policy as well.
- If CFW policy allows port 80, policy evaluation is stopped and the final verdict is allow.
- If CFW policy is disabled, the proxy continues evaluating the next policy and hits block.
Traffic Steering Types
A quick definition of the various traffic steering types in Netskope Client:
- Cloud Apps Only: Steers only selected applications to the Netskope gateway for deep analysis.
- Web Traffic: Steers all HTTP(S) traffic (typically on port 80 & 443) to the Netskope gateway for deep analysis.
- All Traffic: Steers all HTTP(S) and non-HTTP(S) traffic to the Netskope gateway for deep analysis.
- None (New with Flexible Dynamic Steering): The Netskope Client does not establish a tunnel or steer any traffic.
Dynamic Steering Behavior Based on Flexible Dynamic Steering Enablement
The Netskope Client’s dynamic steering allows traffic mode changes based on the endpoint’s location (on-premises or remote). The specific behavior depends on whether “Flexible Dynamic Steering” is enabled in your Netskope tenant (available from Client version 112.0.0 onwards).
1. When Flexible Dynamic Steering is NOT Enabled (Legacy Behavior)
For tenants or clients where Flexible Dynamic Steering has not been enabled (or for older Client versions/operating systems that do not support it), the dynamic steering behavior is as follows:
- Dynamic steering based on location:
- Netskope Client traffic steering type automatically changes to “Cloud Apps Only” when the endpoint is detected as on-premises.
- Netskope Client traffic steering type automatically changes to “All Traffic” when the endpoint is detected as remote (off-premises).
2. When Flexible Dynamic Steering IS Enabled (Enhanced Behavior)
With Flexible Dynamic Steering enabled (contact Netskope Support for existing tenants, automatically enabled for new tenants), administrators gain granular control over steering modes for both on-premises and off-premises scenarios. This allows for customized policies beyond the fixed “Cloud Apps Only” / “All Traffic” paradigm.
- Configurable Dynamic Steering based on location:
- For On-Premise scenarios, administrators can select the desired steering mode from:
- Cloud Apps Only
- Web Traffic
- All Traffic
- None (Client does not steer traffic)
- For Off-Premise (remote) scenarios, administrators can select the desired steering mode from:
- Cloud Apps Only
- Web Traffic
- All Traffic
- None (Client does not steer traffic)
- For On-Premise scenarios, administrators can select the desired steering mode from:
This enhanced flexibility allows organizations to define precise steering policies for different network environments.
Netskope Client Fallback Behavior
The Netskope Client is designed to gracefully handle situations where the ideal steering configuration cannot be maintained. In these scenarios, the client may fall back to a “Web Traffic” steering type:
- Netskope Client falls back to “Web Traffic” steering type when the Netskope gateway is not cloud firewall-ready.
- Netskope Client falls back to “Web Traffic” steering type on Windows 7, 8, and 8.1 operating systems.
- Netskope Client falls back to “Web Traffic” steering type on macOS Catalina or earlier operating systems.
- Older versions of Netskope Client fall back to “Web Traffic” steering type when Cloud Firewall is enabled on the Netskope tenant.
Netskope Client Fail Close Behavior
In “Fail Closed” mode, the Netskope Client prioritizes security by blocking traffic when a secure connection to the Netskope Cloud cannot be established or maintained for steered traffic.
- Netskope Client drops both HTTP(S) and non-HTTP(S) steered traffic in “Fail Closed” mode.
- Netskope Client bypasses configured exceptions in “Fail Closed” mode, allowing essential traffic to continue.
- Netskope Client does not drop ICMP traffic in “Fail Closed” mode.
Connected Netskope Client Status
Once the Netskope client is connected to the Netskope gateway, the client configuration window looks like the image below. Notice the Traffic Steering Type is set to All Traffic. It means that the cloud firewall mode is enabled and HTTP(S) & non-HTTP(S) traffic are steered to the Netskope gateway.
