People call it “Zscaler VPN,” then get confused when they see proxy settings, PAC files, or their browser traffic being inspected. Here’s a direct answer: The Zscaler platform is not a single product. Zscaler Internet Access (ZIA) works as a cloud proxy and secure web gateway for internet and SaaS traffic. Zscaler Private Access (ZPA) replaces traditional VPNs for private applications. It uses zero-trust network access (ZTNA) and does not provide full network access. Client Connector is the agent on your device that routes traffic to both. This guide explains how each piece works, how traffic flows, and how to identify which service is active in your setup.

The Direct Answer: ZIA vs ZPA

Feature ZIA (Zscaler Internet Access) ZPA (Zscaler Private Access)
Primary Function Cloud proxy and secure web gateway VPN replacement for private applications (ZTNA)
Traffic Type Internet and SaaS traffic Private application traffic
Access Model Sits between you and the internet to inspect traffic; full network access to the internet Provides application-level access; no direct network access
Agent Client Connector (routes traffic) Client Connector (routes traffic)

ZIA is a proxy and secure web gateway. It sits between you and the internet to inspect traffic. ZPA is a VPN replacement for private applications. It provides application-level access without placing you directly on the corporate network. Client Connector directs traffic to the appropriate service.

Key takeaway: ZIA handles internet and SaaS traffic as a proxy. ZPA handles internal applications via ZTNA. They are distinct services that often work together.

Quick Reference: Zscaler Behavior Based on Destination

You’re accessing… Zscaler component Function What’s happening
Public websites (e.g., Google, news) ZIA Forward proxy/Secure Web Gateway (SWG) Inline inspection and policy enforcement
SaaS apps (e.g., M365, Salesforce) ZIA Proxy/SWG Application controls, Data Loss Prevention (DLP), SSL inspection
Internal web app (in a data center) ZPA ZTNA (VPN replacement) User-to-application connection, no network access granted
Internal RDP/SSH ZPA ZTNA Application-level access with identity checks
Branch office internet breakout ZIA (GRE/IPsec) Proxy/SWG Site traffic tunneled to Zscaler cloud
On-premise low-latency inspection Private Service Edge Local extension Keeps traffic local, reduces latency

ZIA vs ZPA: Architecture

Both services sit between you and a destination, but they do so in different ways.

What Each Service Connects You To

ZIA manages internet and SaaS traffic. It controls, inspects, and logs external internet access. ZPA manages private application access without exposing the underlying network.

For example, opening Gmail uses ZIA (proxy path, inspected). Opening your internal HR portal uses ZPA (brokered connection, identity checked, no network route provided).

How Traffic Flows

ZIA flow: Your device or branch tunnels traffic to the Zscaler edge, which acts as the proxy to the internet.

ZPA flow: Your device connects to the Zscaler Zero Trust Exchange (ZTE) broker. This broker then connects through an App Connector located near the private application. You get application access, not direct network access.

This distinction is important. Troubleshooting involves two different paths. Security considerations also differ: ZIA is for web proxy functions, and ZPA focuses on identity and user/device posture.

Minimal infographic with two side-by-side boxes. Left box labeled Internet and SaaS: Proxy. Right box labeled Private apps: Zero Trust. Top center label: Which Zscaler is Active with simple lines connecting the label to each box. No extra text or icons.

What Gets Exposed

ZPA differs from traditional VPNs. A VPN typically provides network routes, allowing access to parts of the network that may not be necessary (see What is a VPN? | Kaspersky). ZPA avoids this.

  • Reduces risk of lateral movement (users cannot access other segments of the network).
  • No inbound ports are opened for applications.
  • Access is scoped per application and per session.

Inspection and Controls

ZIA performs SSL/TLS decryption, URL filtering, malware and phishing blocking, DLP, and cloud firewall functions. It inspects HTTP, HTTPS, FTP, DNS, and binary traffic within encrypted packets.

ZPA focuses on identity verification, device posture checks, and application segmentation. It does not perform web proxy filtering for the open internet.

Note: When someone mentions “Zscaler blocks websites,” this refers to ZIA performing its filtering function.

What “Zscaler VPN” Often Means

The term “Zscaler VPN” is often used loosely to refer to three situations:

  1. Zscaler Client Connector is installed on the laptop, and the user refers to it as “the VPN.”
  2. ZPA is used for remote access to internal applications, replacing traditional VPN functions (see How to Choose and Harden Your VPN: Best Practices from NSA & CISA).
  3. “Zscaler is on the network path” usually implies ZIA performing proxy inspection on network traffic.

Referring to it as a VPN can lead to incorrect assumptions about its actual capabilities.

How ZIA Functions as a Proxy

ZIA as a Forward Proxy and Secure Web Gateway

ZIA acts as a cloud-native forward proxy. Every request from a user is routed through it before reaching the internet. Policies are enforced in the cloud, including logging, SSL/TLS inspection, threat detection, and DLP.

For example, URL filtering blocks a known malware site. DLP flags an upload containing sensitive data. Both actions occur in real-time.

Where Inspection Occurs

Edge type Description When to use
Public Service Edge Cloud Point of Presence (PoP), routes to the nearest edge Default for most internet traffic
Private/Virtual Service Edge On-premise or virtual extension For latency-sensitive sites or regulated environments

Use Public Service Edge for standard deployments. Use Private/Virtual Service Edge when routing to the cloud causes unacceptable latency or when data residency is a concern.

How Traffic Reaches ZIA

  1. Client Connector: For roaming users with always-on forwarding.
  2. GRE or IPsec tunnels: From branch offices for site-wide coverage.
  3. PAC files: For browser-based proxy routing.
  4. Upstream proxy chaining: When legacy environments require it.

Why ZPA Is Not a Proxy or Traditional VPN

User-to-Application Access

ZPA establishes application-level connections. You do not gain access to a network subnet, nor can you browse the internal network. You receive access only to the specific application for which you are authorized. Identity and device context are continuously checked per session. No inbound ports are opened to the applications, making them inaccessible from the internet.

Key distinction: With a VPN, once connected, you can often reach any resource on the network (see Computer Networks: What is VPN? How it Works? Types of VPN?). With ZPA, you access only the specific authorized application.

The Connector Model: Outbound Only

App Connectors and Branch Connectors are lightweight virtual machines that operate near private applications. They initiate outbound connections to the Zscaler cloud. No inbound traffic is accepted. Users access applications through this brokered path via the Zero Trust Exchange.

Benefit: These connectors cannot be scanned or targeted by Denial-of-Service attacks in the same way a traditional VPN gateway can, as they do not expose an inbound surface.

Synthetic IPs and DNS Steering

When Client Connector is active, it intercepts DNS queries for private applications. This service assigns synthetic IP addresses to these applications, directing traffic through ZPA. The actual server IP addresses are not exposed to the endpoint device. This design hides internal infrastructure from the device itself.

How to Determine Your Current Setup

Consider the Destination

  • For internet or SaaS issues: Focus on ZIA, the proxy path.
  • For private application access issues: Focus on ZPA, the ZTNA path.
  • Important: Both services can be active simultaneously on the same device.

Check Deployed Components

  1. Open Client Connector to verify if ZIA and/or ZPA tunnels are enabled.
  2. Look for PAC file or explicit proxy settings in your browser or system configuration. This indicates ZIA.
  3. Check if internal application hostnames resolve to synthetic IP ranges. This indicates ZPA.
  4. Consult your administrator for logs. ZIA web logs differ from ZPA application access logs.

ZIA vs On-Premise Proxy Appliance

Factor ZIA (cloud proxy) On-premise proxy appliance
Placement Cloud edge, distributed globally Data center, centralized
Scale Elastic, scales automatically Hardware-dependent, fixed capacity
Updates Frequent, automatic by Zscaler Requires manual patching and updates
Remote users Built-in, optimized Often requires additional integration

Constraint: SSL inspection necessitates certificate deployment to endpoints and an exception list. This applies to both ZIA and traditional proxies.

ZIA blocks risky sites, inspects downloads and uploads, and enforces acceptable use policies. Traditional proxies can perform similar basic functions but often require more manual maintenance. Performance for both depends on user proximity to the inspection point.

ZPA vs Traditional VPN

Factor Traditional VPN ZPA (ZTNA)
Access scope Network-wide access Per-application access only
Trust model Implicit trust after initial login Continuous, session-based checks
Lateral movement Easier potential More difficult
Exposure Inbound gateway must be exposed Outbound-only connectors
User experience Traffic may backhaul to central HQ Direct connection to application via nearest edge

Latency, Split Tunneling, and Tromboning

Tromboning refers to inefficient traffic routing where data travels to a central location (e.g., HQ) and then back to its destination. This is common with VPNs when remote users route all traffic through a central concentrator.

ZIA addresses this with distributed Points of Presence (PoPs) and local internet breakout. Traffic routes to the nearest Zscaler edge, not a central hub. Private Service Edges extend this further for on-premise scenarios where cloud routing introduces too much latency.

Common Misconceptions Addressed

“If Zscaler is installed, am I on a VPN?”
No. Client Connector is an agent that routes traffic to ZIA (proxy) and/or ZPA (ZTNA). Neither functions as a traditional VPN.

“Does ZPA hide my public IP on the internet?”
No. ZPA is for private application access only. Your public internet traffic goes through ZIA, and your public IP depends on that routing, not ZPA.

“Is ZIA the same as a browser proxy extension?”
No. ZIA is a comprehensive cloud SWG that intercepts all traffic at the operating system or tunnel level, not just browser HTTP requests. PAC files are one method for directing traffic, but the inspection is far more extensive.

“Can Zscaler function as both a VPN and a proxy simultaneously?”
Yes. Client Connector can send internet traffic to ZIA and private application traffic to ZPA concurrently. This is a standard enterprise deployment.

“Does ZIA inspect everything?”
ZIA can inspect 100% of TLS/SSL traffic. However, most deployments configure SSL inspection exceptions for sensitive categories like financial or health sites. What gets inspected is determined by policy.

Typical Deployment Scenarios

  1. ZIA-only: To control web and SaaS access for all users.
  2. ZPA-only: To replace VPN for internal application access.
  3. Combined ZIA and ZPA: With Client Connector for comprehensive coverage across internet and private applications.
  4. Extended with Private Service Edge: For local performance or data residency requirements.
  5. Hybrid: Maintaining legacy VPN for specific cases while incrementally migrating tasks to ZPA.

Terminology: Proxy, VPN, or Neither?

When discussing specific functions:

  • Use “proxy” or “SWG” for internet filtering, SSL inspection, URL categories, or DLP on uploads. This refers to ZIA functionality.
  • Use “ZTNA” when discussing internal application access without granting network routes. This refers to ZPA functionality.
  • Use “Client Connector” when referring to how traffic is routed from the endpoint device.

Zscaler is not exclusively a proxy nor exclusively a VPN. It encompasses both functions, depending on the service handling the traffic. Using the correct terminology leads to faster troubleshooting, accurate expectations, and improved policy design.

New Research: Deployment & Troubleshooting for SWG (ZIA) and ZTNA (ZPA)

This section details troubleshooting and deployment best practices when both Secure Web Gateway (ZIA) and Zero Trust Network Access (ZPA) services are active on the same device. It also covers tunnel practices for branch-to-cloud connectivity and endpoint agent deployment.

Key Diagnostic Differences

SWG (ZIA) Troubleshooting

  • PAC file validation: Verify proper configuration and download on the endpoint.
  • Inline web traffic logs: Review logs for malware/phishing detection.
  • URL/category filtering: Check logs and policy decision traces.
  • DNS resolution: Confirm proper resolution for proxy egress or default gateway.
  • SSL/TLS inspection: Validate certificates and chain, especially enterprise root certificates.
  • Data Loss Prevention (DLP): Review policy enforcement logs and events.

ZTNA (ZPA) Troubleshooting

  • Client tunnel status: Check TLS connection status and certificate presence.
  • App Connector health: Monitor control and data channel health for the connector VM.
  • Identity/context policies: Review access policy logs, including device posture.
  • Authentication traces: Check SAML or OIDC assertion verification.
  • Connector connectivity: Verify Private Service Edge or on-premise connector connectivity and redundancy.
  • Application visibility: Review logs for application access and lateral movement prevention.

When Both SWG and ZTNA are Active

  • Endpoint agent status: Check indicators for both SWG forwarding and ZTNA tunnel state (connected/disconnected, network trust context).
  • Agent service status: Verify agent processes are running on the operating system and collect agent logs.
  • GeoIP/egress-IP conflicts: If the ZTNA decision engine sees the agent’s egress via the SWG public edge, GeoIP lookups and policy may reflect the SWG egress IP, affecting ZTNA redirection and access controls.
  • Authentication and certificate flow: Test end-to-end (agent → broker/auth endpoint → Identity Provider → connector) to pinpoint failures in SWG, ZTNA, or the IdP.

Common Diagnostic Files to Collect

  • PAC file download logs and timestamps from the endpoint.
  • Agent/connector local configuration and tunnel config files.
  • SAML/OIDC authentication traces and ID token/assertion logs.
  • Packet captures (e.g., tcpdump, WinPCap) on the endpoint and connector VMs for control and data channels.
  • SSL/TLS certificate validation checks (client and server chain), particularly for private Certificate Authorities (CAs).
  • System and service logs for the endpoint agent and local networking stack.
  • App Connector or connector VM logs (control-plane and application-layer).
  • DNS query logs for broker and service endpoints.

Core Verification Approach (Order of Operations)

  1. Agent Configuration: Confirm the endpoint has the correct agent configuration and the latest agent version.
  2. DNS & Reachability: Verify DNS resolution and reachability to necessary infrastructure endpoints (PAC files, agent brokers, login/authentication FQDNs).
  3. Outbound Connectivity: Confirm outbound TLS connectivity (TCP/443) from the endpoint and connector VM to broker endpoints.
  4. Log Analysis: Collect agent logs and packet captures to differentiate SWG vs. ZTNA traffic paths.
  5. Authentication Validation: Validate authentication (SAML/OIDC) traces and any service-issued certificates.
  6. Component Isolation: Temporarily disable either SWG forwarding or the ZTNA tunnel on a test device to determine which component is causing an issue.

Branch Connectivity to SWG (via GRE)

  • Tunnel Establishment: Establish two GRE tunnels from the branch to public SWG edge points in different data centers for high availability.
  • IP Addressing: Use static/public source IP(s) on the branch; avoid sharing source IPs across independent tunnel destinations.
  • Destination Information: The service provider supplies destination IP/hostname(s) for each tunnel after provisioning.
  • Recommended Parameters:
    • L3 mode.
    • Configure source IP/netmask as per provider instructions.
    • Configure tunnel destination IP as provided.
    • Enable keepalives compatible with branch router.
  • Routing:
    • Use static 0.0.0.0/0 via the tunnels or Policy-Based Routing (PBR) to direct site traffic into the tunnels.
    • Implement preemptive failover using priority or PBR rules for primary/secondary tunnels.
  • GRE is typically unencrypted, offering higher throughput. Consider security trade-offs versus IPsec.

Branch Connectivity to SWG (via IPsec)

  • IKEv2: Use IKEv2 for IPsec tunnels.
  • Crypto Best Practices: Configure IPsec transforms with modern cryptography (AES-GCM or AES-CBC with SHA-2 HMAC). If null-encryption is permitted for throughput, confirm policy and compliance.
  • Unique Tunnels: Ensure each tunnel has a unique 4-tuple (source IP/port, destination IP/port); dynamic source ports are often supported.
  • Typical Flow: Add VPN credentials in the provider portal, assign to the branch location, and point to the provider’s SWG VIP/hostname/IP.
  • HA Deployment: Deploy two tunnels to different edge points for high availability.
  • Routing: Use the same routing model as GRE (PBR/static routing for site traffic).

General Deployment and Routing Notes for Branch Connectivity

  • Edge Location: Use provider tools or APIs to find the nearest service edge points and register branch locations (public static IP).
  • Location-based Policies: Create location/group-based policies on the SWG to control inspection and routing for branch traffic.
  • High Availability: Support active/standby or active/active edge pairs; use application-layer (L7) health checks for intelligent failover when available.
  • GRE Provisioning: Provider provisioning for GRE may require support tickets or API registration, depending on the vendor.

Endpoint Agent (Client Connector) Forwarding & Split-Tunnel Behavior

  • The endpoint agent can simultaneously forward internet-bound traffic to the SWG (ZIA) and private-application traffic to the ZTNA service (ZPA). This is a split-tunnel design.
  • Forwarding Profiles: Define:
    • SWG forwarding (full-proxy/tunnel for all internet traffic or split based on policy).
    • ZTNA tunneling for private application access.
    • Trusted DNS and name resolution behaviors.
    • VPN/agent bypass lists for specified FQDNs/IPs.
  • Policy Application: Ensure the agent’s application/profile assignment maps to user/group from the Identity Provider for correct policy application.
  • SSL Inspection & DLP: Enforce SSL inspection and DLP configuration through the agent or enterprise management tools.

High-Level Deployment Steps (Vendor-Neutral Example)

  1. Admin Portal Setup:

    • License the endpoint agent and ZTNA/SWG services.
    • Configure SAML/OIDC authentication for each service.
    • Enable SCIM or user-provisioning if available.

  2. Forwarding Profile Creation:

    • Create forwarding profiles for SWG (tunnel/proxy) and ZTNA (application tunnel).
    • Select tunnel behavior (full proxy vs. split-tunnel) and platform-specific options (drivers, WFP/filtering on Windows).

  3. Application Profile and Policy Assignment:

    • Map forwarding profiles to application/device/user groups.
    • Configure SSL inspection certificates (enterprise root or custom CA) and deploy to endpoints via enterprise management.

  4. Device Deployment:

    • Package the agent for your MDM/endpoint management tool and deploy to pilot groups first.
    • Command-line installer examples vary by vendor; ensure correct parameters for tenant/host/cloud names.
    • Follow a phased rollout: small pilot → controlled group expansion → full deployment.

  5. Authentication and Enrollment:

    • Verify the user authentication flow: agent initiates connection to the broker → Identity Provider SAML/OIDC exchange → device certificate issuance (if ZTNA uses device certificates) → tunnel establishment.
    • Collect logs and certificate artifacts during enrollment for troubleshooting.

Operational and Policy Recommendations

  • SSL/TLS inspection: Create inspection profiles, deploy enterprise root certificates to endpoints, and establish bypass rules for sensitive categories (e.g., banking, healthcare) as required for privacy or compliance.
  • Policies: Implement URL filtering, firewall rules (block non-standard ports), and bandwidth/QoS policies for site traffic.
  • Log Correlation: Use agent and service logs to correlate events across SWG and ZTNA (authentication, policy decisions, inspection results).
  • Phased Enforcement: Test with pilot users and monitor impact before widespread enforcement.

ZTNA App Connector / Connector VM Details

  • Outbound Connectivity: Connectors should use outbound-only TLS (TCP/443) to broker/control-plane endpoints. No inbound ports are typically required.
  • DNS & Outbound HTTPS: Ensure DNS resolution of broker endpoints and unrestricted outbound HTTPS access from connectors.
  • Firewall Allowlisting: If your network firewall requires allowlisting, obtain the provider’s published IP ranges/FQDNs and create outbound allow rules; keep these rules updated.
  • Sizing: Follow the provider’s minimum memory/CPU guidance for Connector VM sizing (e.g., 4 GB RAM is a common baseline; adjust based on load).

Key Prerequisites and Network Requirements

  • Outbound HTTPS (TCP/443) Access: Required from endpoints and connectors to provider broker endpoints.
  • DNS Resolution: For broker and service endpoints (test with dig/nslookup).
  • Default Gateway/Internet Access: From the connector VM or host; no inbound firewall rules are needed for normal operation.
  • Restrictive Networks: If using restrictive network appliances, plan for allowlisting provider control-plane IP ranges or FQDNs.
  • Security Practices: Use secure authentication and certificate management practices; monitor certificate expirations.

Troubleshooting Checklist (Concise)

  • Confirm agent version and configuration on the endpoint.
  • Verify DNS resolution and connectivity (TCP/443) to broker/authentication endpoints.
  • Collect PAC and agent logs, SAML/OIDC traces, and packet captures for control and data channels.
  • Validate SSL/TLS certificate chains for inspection and broker endpoints.
  • For branch tunnels, confirm GRE/IPsec status, keepalives, and route tables.
  • Isolate components by toggling the SWG forwarder or the ZTNA tunnel on a test device to determine the failing component.

Appendix , Security and Compliance Notes

  • GRE Encryption: GRE without encryption boosts throughput but reduces confidentiality. Consider IPsec if data confidentiality is crucial.
  • IPsec Cryptography: Use modern cryptographic suites for IPsec (AES-GCM or AES with SHA-2 HMAC).
  • SSL Inspection Policies: Manage SSL inspection policies carefully to avoid privacy or regulatory violations; maintain allowlists for sensitive domains.

FAQs

1. Is Zscaler a proxy server?
Zscaler Internet Access (ZIA) is a cloud-native forward proxy and secure web gateway. It inspects internet and SaaS traffic, including SSL/TLS decryption. Zscaler Private Access (ZPA) is not a proxy; it is a ZTNA solution for private application access. Therefore, ZIA is a proxy, while ZPA is not.

2. Is Zscaler VPN the same as a traditional VPN?
No. What people refer to as “Zscaler VPN” is typically ZPA or Client Connector. ZPA provides application-level access through outbound-only connectors with continuous identity checks, without placing you on the network. Traditional VPNs provide encrypted network access with implicit trust after login. These are very different models.

3. Can Zscaler replace both a VPN and a proxy server?
Yes. ZIA replaces or enhances the corporate proxy or secure web gateway. ZPA replaces the remote access VPN. Running them together with Client Connector provides a cloud-native, zero-trust architecture that can replace both functions.

4. Why does Zscaler appear as a proxy in my browser settings?
If you see proxy settings or a PAC file directing to Zscaler, it indicates ZIA is routing your browser traffic through its cloud SWG. This is one method for forwarding traffic; others include Client Connector tunnels and GRE/IPsec from branches. The proxy setting is simply how traffic is steered to ZIA for inspection.

Built using Zscaler product documentation and architecture references.