Understanding Your Traffic: Preview the Impact of Steering Decoupling Migration

Hi Community,

To simplify proxy processing, Netskope is decoupling Steering Configuration from proxy processing.

Currently, under the Coupled Proxy model, a Steering Exception acts as both a steering bypass and a proxy bypass, which can cause unexpected SSL decryption and Real-time Protection (RTP) behavior. With the Decoupled Proxy model, Steering Exceptions function solely as steering bypasses, allowing the Netskope Proxy to evaluate SSL and RTP policies independently.

I am sharing the dashboard that generated the attached example report (Steering_Decoupling_Migration_Traffic_Demo) so you can obtain a corresponding report for your own tenants and evaluate how this migration will affect your specific traffic landscape.

UPDATES & IMPROVEMENTS: Enhancements to the Dashboard

To help you troubleshoot and analyze non-standard port traffic more effectively, I have made key updates to the dashboard.

[!NOTE] Action Required: If you previously imported this dashboard, please download the updated dashboard attached to get access to these improvements:

• Enhanced Non-Standard Port Widget: Added columns for Source IP (User) and URI Port to enable faster analysis and identification of specific activity.

• Visual Reference: Added a screenshot showcasing an example of the updated Non-Standard Ports widget in action.

Impact & Best Practices Across Access Methods

To help you prepare, here is how the decoupling behavior applies across different steering methods:

1. Netskope Client (NS Client)

• Impact: No functional change. All the steering exceptions continue to function exactly as they do today.

• Mechanism: The client retrieves steering exceptions and non-standard port configurations upon tunnel establishment. Traffic matching an exception goes directly to the internet —it never reaches the Netskope Cloud.

• Key Concept: Conceptually, these should be viewed strictly as Endpoint Steering Exceptions, as they are evaluated and enforced entirely on the client workstation.

2. IPSec / GRE Tunnels

• Impact & Best Practice: Manage bypasses at the network edge. Traffic intended to bypass Netskope should be routed directly to the internet at the edge device (e.g. router or firewall) rather than forwarded into the tunnel. You maintain full routing control over what enters the tunnel.

• Netskope Egress IP Requirements: If a destination enforces source-IP allowlisting requiring the Netskope egress IP, route the traffic through the tunnel and bypass inspection in the cloud using SSL Decryption (Do Not Decrypt) and Real-Time Protection (Allow/Bypass) policies.

3. Explicit Proxy

• Impact & Best Practice: Manage bypasses via the PAC file. Traffic intended to bypass Netskope should return DIRECT in the PAC file. This prevents the request from being forwarded to the Netskope proxy and keeps traffic routing under customer control.

• Netskope Egress IP Requirements: If destination IP restrictions require traffic to originate from Netskope egress IPs, direct the traffic to the Netskope Explicit Proxy via the PAC file, then use SSL Decryption and Real-Time Protection policies to tunnel the connection without payload inspection.

Key Areas Addressed by this Dashboard

This dashboard tracks two primary traffic impacts associated with the steering decoupling migration:

1. Proxy Bypasses Due to Steering Exceptions:

   • Current State: Steered traffic matching specific Steering Exceptions (such as Domain or Category) bypasses proxy inspection (Bypass Traffic = Yes, with a Bypass Reason starting with Steering Exception).

   • Impact / Action Needed: During the migration, Netskope automatically converts these proxy bypasses for access methods different than the Netskope Client into dedicated SSL Do Not Decrypt and RTP Allow policies to preserve your existing access controls. This dashboard helps you identify which traffic currently relies on this behavior so you can review and clean up policies before or after migration.

2. Non-Standard Port Traffic Management:

   • Current State: Under Coupled Proxy, the Netskope Proxy restricts traffic on non-standard ports (ports other than 80 and 443) by default, generating blocks with the Action Reason unallowed-custom-port unless configured otherwise.

   • Future State: Under Decoupled Proxy, all ports are allowed by default, and access control moves entirely to RTP policies using Service profiles.

   • Dashboard Insights: This widget monitors traffic blocked due to unallowed-custom-port. In this specific run, no results (0 events) were returned, indicating no non-standard port blocks during the analyzed window.

   

Summary of Findings (Based on Attached PDF)

Next Steps & Resources

• Analyze Your Tenant: Deploy this dashboard in your tenant to measure your current volume of Steering Exception proxy bypasses and verify if any custom-port traffic is being blocked.

• Prepare Policies: Review your SSL Decryption and RTP policies, and build Service Profiles for any custom ports to ensure a smooth migration.

• Documentation: For full technical details and migration steps, check out the official Migration Guide for Steering Configurations.

Updates & Improvements:

• Steering Decoupling Non-Standard Port Traffic Widget: Added columns for Source IP (User) and URI Port for faster analysis.

• Screenshots: Added a screenshot with an example of the updated Non-Standard Ports widget.