Local Broker Selection and Fallback

Introduction

Clients and Publishers will build outbound tunnels to gateways on Local Brokers (LBRs), similar to Cloud Brokers., similar to Cloud Brokers. This guide explains the two selection methods and their fallback behavior so you can configure them with confidence.

• DNS hostname-based selection
• Latency-based (GSLB) Broker Selection

DNS Hostname-based Selection

This method uses a configured DNS Hostname in the Local Broker settings to direct clients/publishers to an LBR. This method is simpler but less flexible than latency-based selection and is best kept as a fallback when latency-based (GSLB) selection isn’t available.

Clients

• Clients try the Local Broker (LBR) first.
• If the Local Broker hostname resolves to multiple IPs, the Client validates reachability to each and then selects one at random.
• If multiple LBRs are resolvable/reachable, the Client fails over to the next LBR when the active one fails.
• If no LBR is available, the Client falls back to a Cloud Broker.
• Deploy at least two LBR instances. With only one LBR, failures force a fallback to Cloud. After the LBR recovers, the Client won’t return to it until the tunnel is re‑established.

Publishers

• Deploy one or more dedicated Publishers for each Local Broker (LBR).
• If the LBR hostname resolves to multiple IPs, the Publisher validates reachability to each and then selects one at random.
• If multiple LBRs are resolvable/reachable, the Publisher fails over to the next LBR when the active one fails.
• Unlike Clients, Publishers do not fall back to Cloud Brokers if no other LBR is available.

Latency-based (GSLB) Broker Selection

Latency-based Broker selection extends GSLB selection to Local Brokers and is Netskope’s recommended approach. Enabling this feature for a tenant with Local Broker entitlement provides several benefits:

• Improves performance and user experience by connecting users to the optimal Local Broker based on latency (GSLB).
• Reduces the need to create and manage complex DNS configurations for hostname-based connectivity, simplifying network operations.
• Offers flexibility with preference ordering (Cloud vs. Local), allowing limited Local Broker enablement during testing and gradual rollout.
• Ensures a consistent experience across Cloud and Local Brokers.

Latency-based Broker Selection decides how Netskope Private Access routes traffic either between:

• Local Brokers (LBRs) – Netskope software that delivers ZTNA in your environment; or
• Cloud Brokers in the Netskope cloud.

This setting applies to:

• Clients – which gateway/broker they connect to
• Publishers – which gateway/broker they stitch to

Broker selection is latency-aware, so traffic uses the closest, fastest broker while honoring your policy preferences.

Before You Begin

Make sure you:

• Enable the feature flag for Latency-based Local Broker Selection (Client and Publisher) for your tenant. This feature is Generally Available from release R136 and will be a tenant configuration option in an upcoming release. Meanwhile, contact your Netskope SE or Netskope Support to enable it if needed.
• Enable Latency-Based Local Broker Selection for your tenant. This feature is Generally Available from release R136 and can be enabled directly from the Netskope UI:
  For Clients: Navigate to Settings -> Security Cloud Platform -> Netskope Client → Client Configuration → Global Attributes → Private App tab and enable Enable Latency-Based Local Broker Selection for Clients.
  For Publishers: Navigate to Settings -> Security Cloud Platform -> Traffic Steering → Publishers → Publisher Global Attributes and enable Enable Latency-Based Local Broker Selection for Publishers.
• Deploy at least one Local Broker.
• Determine whether each Local Broker should serve on‑prem, off‑prem, or both user types.
• Have existing Steering Configurations with Dynamic Steering enabled for Netskope Client.
• Configure at least one Publisher for Netskope Private Access.

Client to Local Broker Selection and Fallback

Prerequisites

Configure Local Broker locations, IPs and public IP restrictions as per steps outlined here.

• Enable gateway selection and latency‑based selection for clients as per steps outlined here.

Understand How Client Gateway Selection Works (latency-based)

Client gateway selection:

• Evaluates the user’s location (on‑premises vs off‑premises).
• Applies your Primary/Fallback choices for that location.
• Considers all eligible Local and Cloud brokers.
• Ranks brokers using latency measurements. The client measures round-trip latency (RTT) to each broker’s RTT endpoints, including LBR RTT on TCP port 2443.
• Connects the client to the best available broker and maintains a single active tunnel.

Configuration options per user type (on‑premises and off‑premises):

• Primary gateway type
  • Local Broker
  • Cloud Broker
• Fallback gateway type (optional)
  • Local Broker
  • Cloud Broker
  • None
• Optimal Latency Gateway Selection (optional)
  • Allows a clearly faster alternative gateway type to be used instead of the primary.

Important to note – When latency-based broker selection for clients is enabled, and Gateway Selection is configured for a Steering config, clients attempt connectivity to Local Brokers based on primary versus fallback settings. Without Gateway selection in a steering configuration, clients prefer connectivity to Cloud Brokers by default, with no fallback to Local Brokers.

This lets you enable the feature, validate the configuration, and gradually move users to Local Brokers without unexpected routing changes.

When latency-based broker selection for clients is not enabled, clients use the DNS hostname-based method, which prefers Local Brokers first and falls back to Cloud if no Local Broker is available, as described in the DNS hostname-based selection section above.

Understand Client Fallback Behavior

Client fallback behavior is controlled by your Steering Configuration:

• Fallback within the same type
  • If one Local Broker is unavailable, the client can try other Local Brokers that match your policy.
• Fallback to another type
  • If you configure a fallback type, the client can fall back from:
    • Local Broker → Cloud Broker, or
    • Cloud Broker → Local Broker.
• No fallback
  • If you set Fallback = None, the client only uses the primary gateway type.

This lets you control whether clients can ever move to Cloud Brokers when Local Brokers are unavailable, or must remain local.

Understand Optimal Latency Selection for Clients

Optimal latency selection:

• Normally, gateway selection:
  • Prioritizes the Primary type (Local or Cloud).
  • Sorts brokers by latency within that type.
• When Optimal Latency Gateway Selection is enabled:
  • If a broker of the non‑primary type is significantly faster, the system can choose it.
  • Example:
    • Primary = Local Broker
    • A Cloud Broker is much closer and faster
    • The client may use the Cloud Broker for better user experience.

Use this option when you want to prefer local gateways, but still allow the GSLB service to correct clearly sub‑optimal performance.

Understand Client Behavior when GSLB is Unavailable

If the global broker selection service (GSLB) is temporarily unavailable:

• The client falls back to DNS‑based resolution:
  • Uses the configured Local Broker hostname for Local Broker connections.
  • Uses standard cloud gateway DNS for Cloud connections.
• When GSLB becomes available again:
  • The client returns to latency‑based selection.

This keeps Private App Segment Access usable even if GSLB selection is temporarily unavailable.

Understand Client Primary–fallback Flow

When establishing a connection:

1. The client uses gateway selection to retrieve and order candidate brokers (respecting your Primary setting and, if enabled, optimal latency rules).
2. The client attempts to connect to those brokers in order.
3. If all candidates from the primary type fail and a Fallback type is configured:
   • The client attempts gateways of the fallback type.
4. If Fallback = None, the client retries only the primary type.

This flow helps you predict and troubleshoot how a client moves between Local Brokers and Cloud Brokers.

Publisher to Local Broker Selection and Fallback

Prerequisites

• Enable Publisher connectivity to a Local Broker as outlined here.
  
• When Connect to Local Broker is On, the Publisher uses Local Brokers only and never falls back to Cloud Brokers.

Understand how Publisher gateway selection works (lattency-based)

When Connect to Local Broker is enabled:

• Publisher finds suitable local brokers using the GSLB service.
• GSLB service selects the best local broker based on latency. The publisher measures round-trip latency (RTT) to each broker’s RTT endpoint on TCP port 2443.
• The Publisher establishes a single active connection to that Local Broker.
• Over time, if latency to another Local Broker is better, the Publisher can auto-reconnect to that broker based on pre-defined criteria.

Configuration options:

• At the Publisher:
  • Connect to Local Broker: On (Local only) or Off (Cloud only).
• At the Local Broker:
  • (Optional) DNS Hostname for fallback when GSLB is unavailable.

This keeps the decision per Publisher simple, local‑only or cloud‑only, while the GSLB service chooses the specific instance.

Understand Publisher fallback behavior when GSLB is unavailable

When Latency based Local Broker selection for Publishers is enabled:

• If the GSLB service is temporarily unavailable or cannot find a usable Local Broker:
  • If a Local Broker DNS hostname is configured, the Publisher can use DNS to connect.
  • If no hostname is configured, the Publisher continually retries selection until it succeeds.
• There is no automatic fallback to Cloud when Connect to Local Broker = On.

This preserves a clear separation between Publishers that must stay local and those that may use cloud.

Understand optimal selection for Publishers

For Publishers, “optimal” means selecting the best available Local Broker:

• The GSLB service considers:
  • Publisher location, Local Broker locations and latency between them
• The Publisher:
  • Connects to the best Local Broker and can auto re-connect to a better Local Broker when there is a clear improvement.

You only decide whether the Publisher should use Local Brokers; the GSLB service manages which specific Local Broker is used.