The Hybrid Hustle: Optimizing Traffic Forwarding for Managed Devices

Remember the Hollywood spy thrillers where a stereotypical hacker working from a dimly lit basement bypasses the mighty FIREWALL to hack into Evil Corp Inc. using a Nokia 6600 and a VPN?

Behind the dazzle lies a sobering truth—the failing perimeter-defense.

Not too far in the past, cybersecurity was a relatively simple, linear endeavor. Cut to the present day—a nomadic workforce on public networks, increased resilience on cloud services, BYOD boom, and what have you—security now is like riding a unicycle with a blindfold while juggling flaming swords.

Bad actors are no longer knocking on the front door; they're slipping in through every crack and crevice they can find, and just as you'd no longer protect a modern city with medieval walls, you can't secure a global, flexible team with a rigid, centralized network.

This need for enhanced connectivity coupled with the evolving user access security for a hybrid workforce explains the surging traction behind zero rust architectures—to the extent that a recent White House executive order mandates that all federal agencies adopt one by 2024.

The Disparate Distributed Data Mesh

Let’s take a moment to decipher the complex tapestry of digital interactions between numerous traffic and data channels across the enterprise network in a hybrid setup.

→The network traffic between remote workers, branch offices, and HQ—primarily dominated by VPNs. This traffic can further be distilled into RDP, FTP, DNS, remote access solutions, database traffic, and a dozen other formats.

With the likes of Gartner projecting almost 75% of organizations to go hybrid by the end of 2024, this flow will only multiply many fold. 

→Then there’s the traffic originating from vendors, partners, and third parties. Did you know that in 2021, 33% of all attacks in the healthcare sector were linked to third parties? Also, the fact that almost 54% of businesses do not vet third-party vendors properly?

→ And how can we not mention the proliferation of cloud services and SaaS applications? With an average of 1,295 cloud services perenterprise, around 94% of all companies globally utilize cloud services in their operations. I’ll let you do the network traffic maths.

Overall, the enterprise network serves as a conduit for a diverse array of traffic and data, originating from a plethora of sources. Navigating this intricate web of connectivity requires the right blend of security and traffic forwarding capabilities.

Traffic Forwarding to The Zero Trust Exchange

Alright, so we know that perimeter bound security is obsolete and we know that we have data coming in from a magnitude of sources. Let’s come to the part where Zscaler can help.

The Zero Trust Exchange (ZTE) provides a centralized point for securing and managing network traffic, regardless of where the user is located or what device they are using.

Whether the traffic originates from users within the corporate network, remote workers, branch offices, or even mobile devices, Zscaler ZTE ensures that it is forwarded through the Zscaler cloud to enforce policies and protect against threats before reaching its destination.

Traffic Forwarding from Managed Devices

Managed devices, including corporate laptops and mobile devices, can seamlessly connect to the ZTE using methods such as PAC files and Zscaler Client Connector.

ZCC further offers multiple tunneling options, including Tunnel 1.0, Tunnel with local proxy (TWLP), and Tunnel 2.0—each tailored to specific use cases and security requirements.

a. Proxy Auto-Configuration (PAC) Files

PAC files enable organizations to centrally control and distribute proxy settings to managed devices. By configuring endpoints to use PAC files, traffic can be routed through the ZTE, where it undergoes inspection and policy enforcement before reaching its destination.

When a user accesses a website or resource, their browser consults the PAC file to determine the suitable proxy server, following logic defined within the file. This selected proxy server, often a Zscaler enforcement node located in the cloud, acts as an intermediary, routing the HTTP or HTTPS traffic and enforcing security policies.

PAC files allow for dynamic updates, ensuring that traffic forwarding rules adapt to changes in network configuration or security policies in real time.

b. Zscaler Client Connector (ZCC)

ZCC serves as a lightweight client application installed on managed devices, facilitating secure connectivity to the ZTE.

When installed on a user’s device, for the ZIA use case, the user traffic is tunnelled directly to the nearest ZIA Service Edge for inspection (by default). ZCC uses geolocation information to find the closest ZIA Service Edge node and builds a lightweight Z-Tunnel to it.

The user traffic is then tunnelled to the ZIA Service Edge for inspection and policy enforcement. ZCC can also be set to disable itself temporarily when it detects that it is on a trusted network, or if a captive portal is blocking access to the internet.

ZCC offers multiple tunnelling options, each tailored to specific use cases and security requirements:

1. Tunnel 1.0: Tunnel 1.0 provides a secure tunnel between the client device and the ZTE, ensuring confidentiality and integrity of data in transit. This tunnelling option is well-suited for traditional remote access scenarios, offering robust security without compromising performance.

There are different Tunnel forwarding modes that can be selected within the Zscaler App Forwarding profile and are also dependent on the windows driver type, i.e., route-based or packet filter-based.

Z-tunnel 1.0 forwards traffic to the Zscaler cloud via connect requests—much like a traditional proxy it sends all proxy-aware traffic or port 80/443 under TCP, depending on the forwarding profile configuration. The forwarding profile also depends on OS driver type, i.e., route-based or packet filter-based.

With Tunnel 1.0 there are different tunnel forwarding modes that can be selected within ZCC. Also, it is a non-persistent tunnel—created on demand and for every new request a new tunnel is established.

2. Tunnel with Local Proxy (TWLP): TWLP leverages a proprietary protocol optimized for low-latency and high-performance connectivity. By encapsulating traffic at the transport layer, TWLP minimizes overhead and ensures efficient utilization of network resources, making it ideal for latency-sensitive applications and real-time communication.

3. Tunnel 2.0: Tunnel 2.0 has a tunnelling architecture that uses DTLS or TLS to send all endpoint traffic to the Zscaler cloud—regardless of port or protocols.

Tunnel 2.0 supports non-web traffic in addition to web traffic and offers enhanced features such as application-aware routing, per-app tunnelling, and advanced threat protection. By dynamically steering traffic based on application characteristics and security policies, Tunnel 2.0 optimizes performance and minimizes exposure to cyberthreats.

So Which Traffic Forwarding Method Works Best For You?

Tunnel 1.0

• Suitable for forwarding standard web traffic securely
• Enables transparent forwarding, even for non-proxy aware applications
• Implements unified authentication, including non-SAML aware apps
• Adapts to environments lacking a default route
• Effectively secures TCP port 80/443 traffic
• Compatible with firewall filter applications and other proxies

Consider TWLP or Tunnel 2.0 if:

• Stream conversion is needed
• You need to enforce inbound firewall rules
• Higher visibility into non-web traffic and logs is required

Tunnel With Local Proxy (TWLP)

• Efficiently forwards standard web traffic, including non-standard ports
• Implements unified authentication, accommodating non-SAML aware apps
• Supports environments without a default route
• Seamlessly coexists with the default route VPN on macOS
• Ensures security for all HTTP/HTTPS traffic, even on non-standard ports
• Utilizes lightweight tunnels without stream conversions
• Interoperates with VPN with minimal issues

Consider Tunnel 2.0 if:

• More than traffic proxying is needed
• Browser enhancement protection is required
• Higher log visibility is needed

Tunnel 2.0

• Efficiently forwards all standard web traffic, including non-standard ports
• Enables transparent forwarding, even for non-proxy aware applications
• Implements unified authentication, even for non-SAML aware apps
• Manages client local IP policies, bypasses, exclusions, and inclusions
• Adapts to environments without a default route
• Ensures security for all IP unicast traffic
• Employs tunnel encryption, validation, and integrity measures
• Provides flexible include/exclude options
• Establishes a real-time control channel for efficient management
• Delivers excellent end-user visibility

PAC Forwarding

• Lightly forwards all standard web traffic
• Facilitates forwarding web traffic on non-standard ports
• Supports environments without a default route
• Serves as a lightweight proxy-only solution
• Proxy settings enforced by client connector
• Provides reasonable end-user visibility

Limitations

• Limited to proxying traffic only
• Requires user authentication in the browser
• Log visibility may be limited

Closing Thoughts

Picking the right traffic forwarding method is like choosing the right dance partner for your network—you want someone who's nimble, flexible, and won't step on anyone's toes.

Whether it's prioritizing low-latency connections for real-time applications or optimizing bandwidth allocation to accommodate a diverse workforce, the chosen forwarding method directly impacts productivity and user experience.

Look at the Traffic Forwarding options available to you on our help portal. Our Best Practices guide helps you along the journey of deciding on the best traffic forwarding mechanism to use.

Ready to start a conversation? www.zscaler.com/company/contact