Retiring VPN for a Mixed Workload Estate: What ZPA Can and Cannot Carry
A global manufacturer with 3,200 employees across 14 sites is retiring its remote-access VPN in favour of ZPA. The operations team depends on four things: a web front end to the manufacturing execution system (MES) on TCP 443; a thick-client admin console that opens TCP 1433 to a SQL cluster; a legacy licensing service whose server opens a reverse TCP connection back to the client on a random high port; and a NOC tool that monitors servers by pinging them over ICMP. The MES front end must also be published to 240 third-party contractors who support line-side devices. App Connectors can be placed in any of the 14 sites or in either of the two data centres. Security wants zero inbound firewall openings and contractor access limited to the front end only.
1. Classify each of the four workloads as deliverable through ZPA as-is, deliverable only with a design or application change, or not deliverable. Justify each classification.
Read the worked answer
MES web front end - yes as-is. A domain-based application segment (mes.example.com, TCP 443) with a server group mapped to connectors that can reach the MES servers. Identity and authorisation come from the IdP, not from network position.
SQL admin console - yes as-is, scoped. ZPA proxies TCP, so a segment on the SQL cluster, TCP 1433, restricted to the DBA group works. The connector needs only L3 reachability to 1433; no inbound rule on the SQL host or its firewall.
Reverse licensing callback - no, requires an app change. The App Connector proxies client-initiated flows only. A server opening a connection back to a client's listening port has no segment to travel through, and 'random high port' cannot be expressed as a segment port at all. Options, in order: change the agent to poll the licence service (best); pin a fixed port and keep a persistent client-initiated session through the segment (fragile, breaks on timeout); or keep a narrow VPN / Privileged Remote Access path for that one service and accept the exception.
ICMP monitoring - no. ZPA does not proxy ICMP. Re-point the NOC check at a TCP health endpoint on the host, or run the check from a management host inside the segment, and use endpoint telemetry for reachability instead of ping.
The judgement point: ZPA is an application-access broker, not a router. Anything that relies on L3 behaviour - ICMP, reverse callbacks, dynamic port ranges, non-TCP/UDP protocols - fails, and finding that out after the VPN is switched off is an outage.
2. How should the contractor population be scoped so that they reach only the MES front end, given the rest of the estate is on the same internal DNS domain?
Read the worked answer
Make the segment the security boundary, not the policy. In ZPA a user can only reach what a segment exposes and an access rule allows; anything with no matching segment is simply not intercepted, which is the property that replaces VPN ACLs.
Design:
- A dedicated segment (or segment group) for the contractor-facing front end only: FQDN app.example.com, TCP 443, no wildcard hostnames, no extra ports. Server group pointed at connectors in the site nearest the MES, with at least two connectors for availability.
- One Allow rule: IdP group 'contractors' to that segment only, with a posture profile (managed device, disk encryption, current OS patch where supported) and a short session/re-auth timeout.
- Staff rules for the SQL and admin segments reference staff IdP groups, so a contractor matches nothing and falls through to no access.
- Add a Block rule for the contractor group as a defensive backstop, but never rely on it: ZPA evaluates top-down, first match wins, so an 'Allow All Users' rule placed above it silently defeats every later deny.
Validate with a real contractor test account and read the ZPA access/user activity logs - they record why a request was allowed or denied, which is also the evidence you hand the auditor.
3. The CISO asks how you will prove to a regulator that no inbound access exists once VPN is gone. Describe the controls and the evidence you would collect.
Read the worked answer
Architecture claim: App Connectors and Client Connector both initiate outbound connections to the Zscaler cloud (TLS 443). No listening port is exposed at the edge, no DMZ reverse proxy is required, and there is no site-to-site tunnel carrying user traffic into the estate.
Evidence to collect:
- App Connector host firewall rules and a port scan from outside the estate showing no open service.
- Connector-to-cloud connectivity shown as outbound only in the ZPA admin console (connector health and group status), plus documented connector placement per site.
- Segment inventory exported from the console: every application segment, the ports it exposes, and the access rules and IdP groups that can match it - this is the authorisation matrix the regulator actually wants.
- Sample of ZPA access logs for a contractor account showing denied attempts to unsegmented hosts.
- Change-management records for the VPN decommission, including the licensing-service exception with its compensating control, owner and review date.
The judgement: 'no inbound' is easy to assert and easy to disprove with one forgotten host published on a load balancer. Prove the negative with a segment inventory plus an external scan, and surface the exceptions honestly rather than hiding them.