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 MeshLet’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 ExchangeAlright, 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 DevicesManaged 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 ThoughtsPicking 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
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.
[[{“value”:”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 MeshLet’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 ExchangeAlright, 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 DevicesManaged 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 ThoughtsPicking 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”}]]
