GlobalProtect vs ZPA — start with Rahul

Rahul: network vs user-to-app

Meet Rahul in Finance. He works from home. Today he uses Palo Alto GlobalProtect. After login, the laptop often receives an internal address such as 10.50.20.45. His device is now “inside.” From there he can typically reach the ERP at 10.10.5.20, \\fileserver\share, RDP to a jump host 10.10.8.15, and anything else the VPN zone plus security rules still allow — printers, cameras, lab VLANs. If malware lands on that laptop, it already has a seat on the network. That is lateral movement by design, not by accident.

Zscaler Private Access never gives Rahul that seat. ZCC authenticates him. ZPA brokers a temporary path only to the applications his group is allowed to reach. Example: Finance may use erp.company.local and one RDP jump host. He cannot open the file server, cameras, or a random 10.10.x.x even if he types the IP. Private apps stay inbound-dark. There is no public GlobalProtect VIP to scan.

Hero · Rahul on the LAN vs Rahul to one app

Five building blocks (learn the words with Rahul)

Train the words before the menus. On the GP side: portal = config server, gateway = VPN enforcement (HIP lands here), split tunnel = include/exclude access routes. On the ZPA side, five objects do the whole job.

ZIA (internet security) is a separate product. You can migrate private access to ZPA without turning ZIA on. Licensing is usually per user in a Zscaler tenant that has ZPA enabled.

Decision · Path A vs Path B

ERP request, step by step

Scenario: Finance user Rahul needs the internal ERP. He is not given a corporate IP. Watch one URL.

Journey · six beats of one ERP session

1. Rahul types the URL

   Browser: https://erp.company.local. ZCC sees a destination that matches Application Segment ERP-Production.

2. Authenticate at the IdP

   ZCC sends him through Entra ID SAML. SCIM must already have placed him in Finance. Login success is not the same as access.

3. ZPA evaluates Access Policy

   Is Rahul in Finance? Is the laptop compliant (if you use posture)? Is the app ERP-Production? All yes → Allow. Any no → deny, even if he knows the URL.

4. Nearest healthy connector is selected

   The Mumbai group DC-Mumbai already has an inside-out TLS 443 session to the ZPA cloud. ZPA tells that connector to reach the ERP on 443.

5. The stitch is user ↔ ZPA cloud ↔ connector ↔ ERP

   Rahul works as usual. He still cannot reach \\fileserver\share or the camera VLAN. Those names are not in a segment he is allowed to use.

6. Proof in Diagnostics

   Green is a log field: user, group, application, connector group, policy name. If policy is Block, do not debug the connector.

How to choose the rollout style

Zscaler’s leading-practices guide names two segmentation approaches. Most GP replacements should start with Discovery-Based Zero Trust. Day-0 Trust is only for teams that already have a complete app-and-group map and can accept blocked business activity for anything they missed.

Infographic · migration map

Recruiter ticket: “everything is on auto-discovery”

A student heard this yesterday: “The company replaced ZPA with VPN (GlobalProtect), but they put everything on an Auto discovery App Segment and they want someone to create App Segments for the rest of the applications.”

Fix the sentence first, then do the job. Recruiters mix the product names. Two readings are both common:

• Reading A (most likely): they replaced GlobalProtect with ZPA, parked every private name on one Application Discovery / wildcard segment, and now hire you to carve real Application Segments. Discovery was never meant to be the end state.
• Reading B: they tried ZPA, left discovery forever, users or auditors screamed, they rolled back to GlobalProtect, and they still need the segment work so they can come back to ZPA without a second outage.

Ask one clarifying question on the call: “Is ZCC still forwarding private apps today, or are users back on GlobalProtect?” The carve-out method is the same. Only the rollback unit changes.

What you actually do in week 1

1. Export the discovery pile

   In ZPA, Application Discovery / recommended Application Segments already lists FQDNs, ports, and which users touched them. Also pull User Activity / Diagnostics for 14–30 days. That sheet is the missing inventory. Source: ZPA Leading Practices — discovery then split and Understanding Application Discovery.

2. Rank before you click Add

   Three buckets only: crown jewel (ERP, payroll, AD/DFS, jump hosts) — define this week with explicit Allow + catch-all Block. Known business app — define this month, map to an IdP group. Long-tail / unknown — leave on discovery until the deadline (Zscaler’s own window is about 60–90 days or ~60% of entitled users).

3. Carve one app the safe way

   Example from this lesson: create ERP-Production for erp.company.local TCP 80,443 — copy every port users actually used in discovery, not “just 443.” Attach DC-Mumbai. Add Allow-Finance-ERP above the discovery Allow. Add Block ERP-Production / Any immediately under it so contractors drop even if they know the URL.

4. Respect the more-specific trap

   The day erp.company.local exists as its own segment, that object wins over *.company.local. If you forget TCP 8443 and users still hit 8443, ZPA drops — it does not fall back to discovery. This is the #1 outage when people “create the rest of the app segments.” Re-read Understanding Application Access.

5. Prove, then remove from the wildcard mentally

   Diagnostics must show the new segment name and the new policy name for Finance users. Contractors must show Block. Only then tick that FQDN off the discovery list. Repeat for SharePoint, jump host, HR, and so on.

6. If they are already back on GlobalProtect

   Do this carve-out while GP is live. Dual-run ZCC with VPN Gateway Bypass. You are not “replacing VPN again.” You are finishing the job they skipped: defined segments + group policy. When a wave is proven, that wave leaves GP. Discovery still stays until the long tail is owned.

7. Kill discovery last, on a calendar date

   After the deadline: disable the wildcard segment, enable a fail-closed Block Any/Any if leadership accepted the risk, and keep a request path (ticket → new segment) for the next app. Discovery with no deadline is just a cloud VPN.

Prerequisites

Do not open the ZPA Admin console until this pack is green. Missing one row is how pilots look “random.”

Project plan

Treat this as a program, not a Friday change window. Safe beginner sequence: IdP + SCIM → connectors in key sites → pilot Application Segments (ERP first) → ZCC on 20 Finance users → GlobalProtect still running → expand apps and groups → decommission GP only after proof. Zscaler’s VPN-to-ZTE write-up is the same idea: assess, map, policy, deploy, IAM, test.

Journey · inventory to cutover

1. Week 0–1 — Assess the current GP estate

   List every portal and gateway FQDN, auth method (SAML, cert, RADIUS, LDAP), HIP objects, split-tunnel includes/excludes, and which security rules match the corp-vpn zone. Capture where traffic is hairpinned through a data-center firewall. Source: GlobalProtect Overview.

2. Week 1–2 — Map apps and owners

   From GP/firewall logs, build a sheet: FQDN or CIDR, TCP/UDP ports, user group, site (DC / AWS / Azure), criticality. Mark crown-jewel apps (payroll, ERP, domain controllers used by DFS). Those get defined segments on day one. Source: Zscaler VPN migration process.

3. Week 2 — Identity

   Stand the ZPA IdP. Map the same NameID you use today. Push SCIM groups that match the GP user groups you already trust. Do not write Access Policy on SCIM attributes until the first sync finishes. Source: Access Policy Deployment guide.

4. Week 2–3 — Connectors and discovery segment

   Deploy N+1 connectors per site. Create location-based connector groups. Add a discovery application segment for the private namespace and a permissive Allow for authenticated employees. Create explicit Allow + Block pairs for crown-jewel apps. Source: ZPA Leading Practices Guide.

5. Week 3 — Dual-run the endpoint

   Package ZCC. In the App Profile, add every GP portal and gateway to VPN Gateway Bypass. If the forwarding profile uses Tunnel mode with a split-tunnel VPN, this field is required. Keep GP always-on for non-pilot users. Source: Configuring ZCC App Profiles.

6. Week 4 — Pilot, then wave cutover

   Pilot IT + one business unit (about 5–10%). Pass the proof checklist in the next section. Then wave by department. After 60–90 days, turn discovery off and keep only defined segments.

Do: segment, policy, connector

Side A is the world you already own (IdP + GlobalProtect stay-alive). Side B is the three ZPA objects beginners actually click: Connector Group, Application Segment ERP-Production, Access Policy Allow-Finance-ERP. Side C is ZCC dual-run. Do them in that order. The Admin path is not “Configuration → Application Segments” — use the documented Policies / Infrastructure paths below.

Pipeline · identity into policy into connectors

Side A — IdP and GlobalProtect stay-alive

1. Freeze the GP change window

   On Panorama or the firewall: Network → GlobalProtect → Portals and Network → GlobalProtect → Gateways. Export the running config. Note portal FQDN, gateway FQDNs, auth profile, and HIP profiles. Do not delete agent configs used by non-pilot users.

2. Publish the same groups to ZPA

   In Entra ID / Okta / AD FS, create or reuse groups that match how you already grant VPN (example: vpn-employees, vpn-contractors, payroll-uk). Enable SCIM toward ZPA. Wait for the first full cycle. Source: Enabling SCIM for Identity Management.

3. Decide the dual-run split

   Pilot users: ZCC on, GP still installed, GP gateways listed in VPN Gateway Bypass so private apps go to ZPA. Non-pilot users: GP only. Helpdesk gets a one-page “disable ZPA / reconnect GP” card before day one.

Side B — ZPA Admin

Primary source for this block: Configuring Defined Application Segments and Configuring App Connector Groups.

1. Enroll connectors and prove they are Up

   Deploy the Linux / VMware / Azure / AWS image. Paste the provisioning key. In the Admin portal, each connector should show enrolled and healthy. From the connector, resolve a private FQDN and curl/nc the app port. Confirm ICMP to the server.

2. Add the discovery application segment

   Path: Policies → Access Control → Private Applications → Defined Application Segments → Add Application Segment. Use a private wildcard, not * (a wildcard-only * needs Zscaler approval and is not for discovery). Bind a server group with dynamic server discovery. Attach the site’s connector group. Open the TCP/UDP ports you actually use — do not blindly punch 1–65535 on a crown-jewel host.

3. Write Access Policy in the right order

   Path follows Configuring Access Policies. Rule action is Allow Access or Block. First-match, most-specific segment. For Rahul’s company, start explicit then discovery:

   Policy order (Finance pilot example)

   1 Allow  ERP-Production            memberOf = Finance  (+ posture if you use it)
   2 Block  ERP-Production            Any
   3 Allow  contractor-apps           memberOf = contractor
   4 Block  Any                       memberOf = contractor
   5 Allow  *.company.local           authenticated employees   ← discovery later
   6 Block  Any                       Any                       ← fail closed after discovery ends

   Do not enable rule 6 (fail closed) until discovery is finished. During dual-run, rule 5 keeps people working the way VPN did.

4. Client forwarding for on-LAN users

   If you want the same Zero Trust path when the laptop is inside the office, add Client Forwarding Policy so those FQDNs still go to ZPA. Same most-specific / first-match rule. A Private Service Edge is the published pattern for local access to specific apps. Source: About Client Forwarding Policy.

Side C — ZCC and the dual-run (coexistence)

1. App Profile — VPN Gateway Bypass

   ZCC Admin → App Profiles (Windows / macOS / …). When a VPN client runs next to ZCC and the forwarding profile uses Tunnel, add every GP portal and gateway as FQDN or IP in VPN Gateway Bypass. An FQDN is resolved once at tunnel start and all resulting IPs are bypassed. Keep this list short. Source: Configuring ZCC App Profiles.

2. Do not use Tunnel on a “VPN-trusted” network as the dual-run design

   Zscaler’s interoperability note warns against forwarding-profile Tunnel (route-based) for a VPN-trusted network. Prefer explicit bypass of the GP destinations, then let ZPA own the private app FQDNs.

3. Pilot ring in the IdP

   Assign ZCC only to zpa-pilot-wave1. Everyone else keeps GP as today. That group is also the rollback unit — you remove ZCC or disable ZPA for that group without touching the company.

20-user Finance pilot

Current state in this example: 200 users still on GlobalProtect to reach about 15 internal apps. Do not start with all 15. A beginner-safe first ring is 20 Finance users, 2 App Connectors in the main DC, and 3 apps: ERP, Finance SharePoint, one RDP jump host. GlobalProtect stays installed. Users can use either path for a few weeks. Then expand coverage, then retire GP.

A pilot is not “IT connected once.” Score named apps, named users, named failure signals. Run at least five business days so Monday-morning thick clients show up.

Ops · proof cockpit

Runtime path after go-live

After cutover, a request does not “hit the gateway.” Walk this path when a user says the app is down.

First-fix when Rahul cannot open ERP

Project rollback plan

Rollback is a designed state, not “turn GP back on and hope.” You keep GlobalProtect authoritative until ZPA has earned the traffic. The rollback unit is a user group or device ring, never the whole company on the first incident.

Keep these objects until the program is closed

• GlobalProtect portal and every gateway (config + public DNS + certificates + licenses).
• HIP objects and the security rules that reference the VPN zone — non-pilot users still need them.
• The IdP app registration for GP. Do not recycle it into the ZPA app.
• A tested “remove ZCC / set ZPA disabled / reconnect GP” runbook for Intune / Jamf / SCCM.

Rollback runbook (wave)

1. Declare the trigger

   Examples: more than 10% of the wave cannot reach a P1 app for 30 minutes; connector group for a site is down and N+1 is gone; IdP outage that ZPA cannot ride through; rollback drill (P7) failed.

2. Stop the bleed

   Move the wave’s IdP group out of the ZCC assignment. Optionally set a Client Forwarding / Access Policy Block for that group so half-connected laptops do not black-hole private FQDNs. Do not delete application segments — you will need them after the fix.

3. Return users to GlobalProtect

   GP app reconnects to the portal, downloads the existing agent config, and builds the gateway tunnel. Confirm HIP and the old security rules still match. Prove the same P2/P3 apps over GP.

4. Leave ZPA standing

   Connectors stay up. Policies stay in place. You lost a wave, not the platform. After root cause, re-enter that wave through the same pilot checklist.

5. Only then retire GP

   When every in-scope group has been on ZPA past the discovery deadline, P7 is unused for 30 days, and leadership signs the risk acceptance: remove gateway DNS, then the portal, then licenses. Never reverse that order.

Beginner traps and proof

Sources

• Zscaler — ZPA Leading Practices Guide (discovery vs Day-0, N+1, 500 Mbps, geo groups, ICMP, 7-day timeout)
• Zscaler — Understanding Application Discovery (wildcard is an inventory engine, then split defined segments)
• Zscaler — Configuring Defined Application Segments
• Zscaler — Understanding Application Access (more-specific FQDN, no port fallback)
• Zscaler — Configuring Access Policies (first-match)
• Zscaler — Configuring App Connector Groups / App Connector Keys
• Zscaler — App Connector Deployment Prerequisites
• Zscaler — Configuring ZCC App Profiles (VPN Gateway Bypass)
• Zscaler — About Client Forwarding Policy
• Zscaler — How to Migrate from VPN to the Zero Trust Exchange
• Palo Alto Networks — GlobalProtect Overview (portal, gateway, app, HIP)
• Palo Alto Networks — Gateway Client Settings / split tunnel

Related: Migration plan · implement · rollback · GlobalProtect lesson · ZPA architecture · App Connectors · ZPA policies · ZPA access policy · Zscaler authentication