Netskope Client Support in Cloud Firewall

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) supports the following operating systems:

If you have a older version of Windows or macOS, refer Netskope Client Dynamic Steering, Fall Back, and Fail Close Behavior.

To configure Netskope client to steer non-HTTP(S) traffic to Netskope Cloud Firewall, follow the steps below:

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:

Then, you can create an App Definition, followed by a Real-time Protection policy. Click the following links to go to the respective procedure:

If you have a requirement for the Netskope client to bypass certain non-HTTP(S) applications, follow the steps below:

When the Netskope client is in “All Traffic” mode or cloud firewall is enabled, the following traffic is bypassed by default:

Documentation on various Netskope client deployment options can be found here.

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:

1. With HTTP-AD disabled, traffic to port 80 or 443 are sent to NSproxy directly.
   1. Other traffic for ports in Steering Configuration > Non-Standard Ports is also sent to NSproxy with the selected domain and port combination.
2. This traffic was destined to 443 and it was sent to nsproxy.
3. NSproxy respects cloud firewall policy as well.
4. If CFW policy allows port 80, policy evaluation is stopped and the final verdict is allow.
5. 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)

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.

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.