Zscaler 101

 

ZIA:

Overview

Zscaler Internet Access (ZIA) is a cloud-delivered secure internet and web gateway designed to protect users, applications, and data, regardless of location. By eliminating the need for on-premises hardware, ZIA provides a full security stack—including firewall, URL filtering, sandboxing, Cloud Access Security Broker (CASB), Data Loss Prevention (DLP), and SSL inspection—through a globally distributed platform. All user traffic is routed to the nearest Zscaler Enforcement Node (ZEN), where it is inspected inline to enforce enterprise security policies consistently across the globe.

Core Architectural Components

ZIA’s architecture consists of three logical planes:

1. Control Plane:

• Manages policy configuration, user authentication, and system settings.
• Hosted in Zscaler’s cloud data centers.
• Administered through a centralized Global Admin Console.
• Responsible for synchronizing policies across all enforcement nodes.
• Manages SSL certificates and authentication methods.

2. Data Plane:

• Enforces security policies in real-time.
• Operated via ZEN nodes located in over 150 data centers worldwide.
• Performs SSL decryption, threat prevention, content filtering, and sandboxing.
• Retrieves user-specific policies from the Control Plane with ~300ms latency.
• Ensures low-latency enforcement close to users.

3. Statistics Plane:

• Collects and processes transaction logs for analytics.
• Logs are compressed and stored in distributed nano-log clusters.
• Supports threat hunting, compliance audits, and SIEM integrations.

Global Admin Console and Certificate Authorities

Global Admin Console:

• Provides a single pane of glass for administrators.
• Used for configuring global policies, monitoring service health, and managing authentication.

Zscaler Certificate Authorities (CAs):

• Issue certificates for SSL inspection.
• Facilitate secure communication.
• Handle certificate pinning exceptions to maintain service integrity.

Zscaler Enforcement Nodes (ZEN or Public Service Edge)

ZENs serve as the distributed enforcement points of the ZIA service.

Key Capabilities:

• Apply user and application policies in real-time.
• Perform SSL inspection and threat detection.
• Support direct peering with major cloud services and CDNs.
• Auto-scale and provide high availability.

Traffic Flow Example: Accessing Facebook

1. User Connection and Authentication:

• User in Miami launches Zscaler Client Connector (ZCC).
• ZCC connects to the nearest ZEN (e.g., Miami POP) based on domain configuration and geolocation.
• User authenticates via Identity Provider (e.g., Okta using SAML).
• ZEN retrieves user policies from the Control Plane.

2. Traffic Inspection and Forwarding:

• ZCC establishes a tunnel to ZEN:
  • Tunnel 1.0: Proxy-based, limited ports.
  • Tunnel 2.0: Full TLS VPN, broader protocol support.
• ZEN inspects traffic inline.
• Approved traffic is forwarded to destination (e.g., facebook.com).

3. Location Awareness:

• If the user moves (e.g., from Miami to Los Angeles), ZCC connects to the nearest ZEN in LA.
• Policies are re-fetched (~300ms latency).
• Re-authentication depends on session policies.

4. Logging:

• Metadata is compressed (30x) and sent to log routers.
• Logs are stored in nano-log clusters.
• Optional Virtual Streaming Service (VSS) can forward readable logs to SIEM tools like Splunk.

Cloud Environments

Zscaler operates several cloud environments for redundancy:

• zscaler.net
• zscalertwo.net
• zscalerthree.net

Purpose of Multiple Clouds:

• Ensure high availability and regional fault tolerance.
• Balance global load across separate infrastructures.
• Enable automatic failover in case of service disruption.
• Maintain continuous service delivery across geographic regions.

Users are assigned a default home cloud, but traffic can shift between clouds during outages or peak usage. Each domain represents a fully operational, isolated cloud environment.

Reference: https://config.zscaler.com

Traffic Forwarding Methods

1. GRE Tunnels:

• Preferred for maximum throughput (~1 Gbps).
• Requires static IP; unencrypted.

2. IPsec Tunnels:

• Supports dynamic IP and encryption.
• Lower throughput (~400 Mbps).
• Enables sub-location policy enforcement.

3. Explicit Proxy / PAC Files:

• User traffic directed to Zscaler via configuration scripts.

4. Zscaler Client Connector (ZCC):

• Installed on endpoints.
• Seamlessly forwards traffic to ZENs.
• Supports roaming and mobile users without manual reconfiguration.

Authentication and Identity Management

ZIA integrates with various identity providers and methods:

• SAML-based SSO (Okta, Azure AD)
• LDAP via Zscaler Authentication Bridge
• Kerberos/NTLM for AD integration
• SCIM for automated provisioning
• Certificate-based authentication for IoT and shared devices

Business Benefits

• Delivers consistent security across users, locations, and devices.
• Eliminates the need for costly on-premises appliances.
• Supports hybrid and remote workforce securely.
• Enhances performance via local enforcement and direct peering.
• Simplifies compliance with centralized logging and reporting.

Conclusion

Zscaler Internet Access provides a scalable, resilient, and secure platform for managing internet-bound traffic in modern enterprises. With a cloud-native architecture, comprehensive feature set, and global presence, ZIA is well-suited for organizations seeking to modernize their network and security infrastructure while supporting the demands of a distributed workforce.

 

 

ZPA:

Overview

Zscaler Private Access (ZPA) is a Zero Trust Network Access (ZTNA) solution designed to provide secure, identity-based access to internal applications hosted in data centers or public clouds. Unlike traditional VPNs, ZPA does not require inbound firewall rules, exposed IP addresses, or DMZ infrastructure. Applications remain hidden from the internet, reducing the overall attack surface and ensuring least-privileged access on a per-application basis.

Key Advantages

• No inbound connections to data centers or clouds
• No exposed IP addresses
• Outbound-only connections simplify firewall policies
• Per-application segmentation eliminates lateral movement
• Dynamic discovery of apps and servers
• Seamless remote access without VPN complexity

Core Architectural Components

Zscaler Client Connector (ZCC):

• Installed on user devices to intercept traffic for private apps
• Performs device posture checks and user authentication
• Establishes outbound TLS tunnels to Public Service Edges

ZPA Public Service Edges (Brokers):

• Cloud-based enforcement nodes that authenticate users
• Map authenticated users to their authorized apps
• Establish secure, application-specific micro-tunnels

Zscaler Central Authority (CA):

• Orchestration layer for policy distribution and broker selection
• Authenticates users and chooses the optimal Service Edge

App Connectors:

• Lightweight VMs or containers deployed near private apps
• Initiate outbound-only TLS tunnels to the ZPA cloud
• Dynamically discover servers and applications

Traffic Flow (ZPA Example)

1. Enrollment and Device Fingerprinting:

• Users install ZCC and enroll devices
• Device certificates are issued, renewed, and revoked as needed
• Revoked devices lose access immediately via invalidated certificates

2. Secure Connection Establishment:

• ZCC and App Connectors initiate outbound TLS tunnels (Z-Tunnels) to the ZPA cloud
• When a user requests access to a private app (e.g., xyz.local), ZCC contacts the CA
• CA selects the best Public Service Edge for optimal connection
• A secure, app-specific micro-tunnel is created without exposing IP addresses

3. Policy Enforcement:

• Access is granted based on user identity, device posture, and application-specific policies
• Unsupported protocols (e.g., ICMP, multicast, active FTP) are blocked by design
• All traffic is inspected inline to enforce Zero Trust principles

Application and Server Segmentation

Applications:

• Defined by FQDN or IP+port
• Automatically discovered and grouped logically

Application Segments:

• Logical groups of one or more applications
• Organized by function, protocol, or department

Segment Groups:

• Collections of Application Segments
• Allow shared access policies, timeouts, and controls

Server Groups:

• Logical collections of backend servers
• Mapped to App Connector Groups for access enforcement

App Connector Groups:

• Groupings of App Connectors by region or environment (e.g., DC1, Azure)
• Provide redundancy and load balancing

App Connectors:

• Actual VMs or containers deployed in data centers or cloud
• Facilitate access by maintaining TLS tunnels to the ZPA cloud

Recommended Nesting Hierarchy

Applications → Application Segments → Segment Groups → Server Groups → App Connector Groups → App Connectors

This nesting model ensures clear mapping between apps, servers, and environments. It improves performance, reduces misconfigurations, and supports easier troubleshooting.

Detailed Explanation of Group Nesting

ZPA’s access model follows a hierarchical chain:

1. Application Segments: Define what applications are accessible
2. Segment Groups: Bundle application segments for unified control
3. Server Groups: Bind apps to infrastructure
4. App Connector Groups: Define which App Connectors can serve specific apps
5. App Connectors: Maintain tunnels and handle secure access

Example:

• DC1-Apps → Application Segment(s) → Segment Group A → Server Group 1 → App Connector Group 1 → DC1 App Connectors
• Azure-Apps → Application Segment(s) → Segment Group B → Server Group 2 → App Connector Group 2 → Azure App Connectors

Benefits:

• Environment-Based Segmentation: Isolate and troubleshoot by location
• Precise Server-to-Connector Mapping: Avoid cross-environment misrouting
• Independent Scaling: Scale App Connector Groups as needed
• Simplified Maintenance: Change without impacting unrelated apps
• Consistent Policy Enforcement: Apply shared settings easily

Conclusion

Zscaler Private Access (ZPA) provides a robust, cloud-native approach to Zero Trust Network Access. By replacing legacy VPNs with identity-based, per-application access, ZPA enhances security posture, simplifies management, and supports a modern, distributed workforce. Its modular architecture and dynamic segmentation capabilities make it ideal for hybrid, multi-cloud enterprises seeking scalable and secure private application access.

 

 

QAs:

Use of 100.64.0.0/16 Subnet in ZPA

ZPA uses the 100.64.0.0/16 subnet as part of the larger 100.64.0.0/10 Shared Address Space defined by RFC 6598. This address space is reserved and not routable on the public Internet. Within ZPA, this range serves a unique purpose in forming an encrypted overlay network.

Key Characteristics:

• Internal Overlay IPs: ZPA assigns virtual IPs from the 100.64.0.0/10 range to represent internal applications. These overlay IPs allow user devices to communicate with private apps as if they exist on this subnet.
• Invisible to the Public Internet: These addresses are used only within ZPA’s secure cloud environment and are never exposed externally.
• No Manual Configuration Required: The address assignment and routing are automatically handled by Zscaler, abstracting the organization’s internal IP addresses.

Practical Summary: This virtual address space allows ZPA to securely map internal apps to overlay IPs, ensuring seamless access without revealing real IP addresses. It also supports ZPA’s zero-trust principle by controlling traffic purely at the application layer.

Zscaler’s Definition of Applications (Including DNS)

In Zscaler, an “application” is a fundamental unit of policy enforcement. Unlike traditional firewalls, which focus on port and protocol, Zscaler identifies and classifies traffic based on application behavior.

How DNS is Treated as an Application:

1. Application Signatures: DNS traffic is identified using signatures that analyze flows to TCP/UDP port 53. Once recognized, this traffic is categorized as the “DNS application.”
2. Policy Precision: Administrators can create rules such as “allow DNS application” rather than relying on open port rules.
3. Application-Aware Model: Whether it’s DNS, HTTPS, or a custom app, Zscaler classifies each as an application, streamlining security management.

Why It Matters: Opening port 53 for DNS doesn’t just allow traffic at the port level—in Zscaler’s model, you must explicitly allow the “DNS application,” which ensures deeper visibility and control.

Do ZPA Applications Each Create Their Own Micro-Tunnel?

Yes. ZPA operates on an application-specific micro-tunneling model. Each private application that a user is authorized to access is served through a separate, dynamic micro-tunnel.

Detailed Behavior:

1. ZCC Establishes a TLS Tunnel: When the Zscaler Client Connector (ZCC) connects to ZPA, it forms an encrypted TLS tunnel to the ZPA cloud.
2. Per-Application Access: When a user requests access to an internal app (e.g., finance.internal), ZPA creates a secure, app-specific micro-tunnel from the device to the app via the closest Public Service Edge and App Connector.
3. Isolation by Design: Each micro-tunnel is isolated. If a user is permitted to access App A and App B, separate tunnels are formed, preventing lateral movement.

Security and Compliance Benefits:

• Least Privilege: Only approved apps are reachable.
• No Network-Level Access: Users cannot scan or reach other services within a subnet.
• Auditability: Each tunnel is logged and can be traced per user, app, and session.

Summary: ZPA’s micro-tunneling architecture enforces zero trust principles by creating isolated, per-application tunnels. This model offers high security, granular control, and robust auditing capabilities.

Unified Zscaler Summary

Zscaler provides two core services under its Secure Access Service Edge (SASE) framework:

• ZIA (Zscaler Internet Access): Secure, cloud-delivered internet access for outbound traffic, replacing traditional proxies and firewalls.
• ZPA (Zscaler Private Access): Secure, application-specific access to private applications without VPNs, DMZs, or network exposure.

Combined Benefits:

• Seamless user experience for internet and private app access
• Zero trust model with consistent policy enforcement
• Centralized visibility and management
• Support for work-from-anywhere

Notes:

• DNS access is defined as an application in Zscaler’s model.
• Each private application accessed through ZPA forms its own isolated micro-tunnel.
• The 100.64.0.0/10 subnet is reserved for internal routing within Zscaler’s overlay network and is not used or visible on your local network.

Zscaler’s approach to security modernizes how organizations provide access, ensuring flexibility, control, and zero trust principles across both internet-facing and internal resources.

 

Common Issues and Limitations to Be Aware Of:

ZPA (Zscaler Private Access)

Common Issues:

• Misconfigured Application Segments: If an application isn’t reachable, it’s often due to an incorrect FQDN/IP range or missing port in the segment definition.

• Improper Server Group Mapping: Application Segments must be properly tied to Server Groups and App Connector Groups. If these aren’t mapped correctly, users will get connection failures.

• Authentication Problems: ZPA relies heavily on IdP integration. If SAML/SCIM syncs fail or user attributes change unexpectedly, access issues can occur.

• Certificate Revocation Delays: Although ZPA revokes device certificates quickly, there may be short windows where recently decommissioned devices still connect if revocation propagation lags.

• DNS Resolution Failures: App Connectors rely on internal DNS to resolve private application FQDNs. Misconfigured or slow DNS can lead to app unavailability.

Limitations:

• No Support for UDP Broadcast, Multicast, or ICMP: ZPA doesn’t support protocols that rely on direct network-level communication.

• Push-Based Protocols May Fail: Server-to-client initiated protocols (e.g., certain VoIP or legacy ERP systems) may not function without specific configuration.

• App Connector Dependency: Loss of all App Connectors in a region or subnet results in application unavailability.

• Max App Connectors per Group: Practical limits exist (~200 per group, region dependent) and should be monitored.

ZCC (Zscaler Client Connector)

Common Issues:

• Stale Policy/Configuration: ZCC caches settings; if policy changes aren’t applied promptly, it may require a restart or manual refresh.

• Tunnel Instability: Users on unstable Wi-Fi or switching networks (e.g., coffee shop to mobile hotspot) may experience reconnect delays or split tunnel failures.

• Device Posture Check Failures: If endpoint security posture changes (e.g., antivirus disabled), ZCC may silently block access depending on policy.

Limitations:

• Multiple Network Interfaces: ZCC may have trouble deciding which interface to use if users have VPNs, Ethernet, and Wi-Fi active.

• No Native Support for All OS Versions: Linux support is limited; some MDM platforms (especially legacy) struggle with ZCC deployment.

• Proxy Chaining Issues: On corporate networks with transparent proxies or custom PAC files, ZCC behavior may be unpredictable without exclusions.

ZIA (Zscaler Internet Access)

Common Issues:

• SSL Inspection Breakage: Sites that use certificate pinning (e.g., banking, some APIs) can fail unless correctly bypassed or handled via Zscaler CA exceptions.

• Latency from Policy Lookups: While ZENs fetch policy within ~300ms, poor performance may result if users are routed to distant data centers.

• Split Tunnel Misconfigurations: If tunnel rules or PAC files aren’t accurately defined, traffic may bypass ZIA unintentionally.

Limitations:

• Limited Port/Protocol Support on Tunnel 1.0: Only basic web ports are supported. Applications using non-standard ports may fail unless Tunnel 2.0 or GRE/IPsec is used.

• Limited Visibility Without SSL Decryption: If you disable SSL inspection, Zscaler can’t inspect content, which reduces DLP/CASB efficacy.

• Cloud Service Misclassification: New or obscure SaaS apps may be miscategorized, leading to overblocking or unfiltered access until corrected.

App Connectors

Common Issues:

• DNS Resolution Fails: They must be able to resolve internal FQDNs. If their upstream DNS is misconfigured, apps won’t resolve even if properly mapped.

• Connector Health Checks Fail: Firewall changes or inspection in the path can interfere with connector-to-cloud health checks.

• Overloaded Connectors: If too many apps are routed through too few connectors, latency and dropped connections can occur.

Limitations:

• No NAT or PAT Support on App Connector Interface: Must be in the same subnet as target apps without address translation.

• No Inbound Connections: App Connectors cannot be reached externally, even for troubleshooting—you must rely on Zscaler diagnostics.

• Latency Impact: Connector placement (too far from app servers) can cause noticeable delay.

Recommendations to Mitigate Common Issues

• Use Zscaler Health and Diagnostic Tools: ZDX, ZCC logs, App Connector logs, and Zscaler Central Authority event tracking are key to root cause analysis.

• Baseline Your Environment: Maintain good documentation of app-to-segment mappings, connector locations, and DNS dependencies.

• Test Before Going Global: Use pilot groups and regional rollouts to validate configurations.

• Keep PAC Files and Tunnel Settings in Sync: Mismatched settings between endpoints and firewalls cause major issues.

• Regularly Audit Policy Exceptions: Temporary SSL inspection bypasses often become permanent. Review quarterly.