PAC Architect Registration cheat sheet

Prisma Access splits into two planes: the management plane (Panorama or Strata Cloud Manager) and the data plane (service connections and compute locations); policy is authored once and pushed to all compute locations.

Compute locations come in two sizes: a full mobile user location hosts explicit proxy, GlobalProtect, and site-to-site termination; a small location supports only a subset (typically GlobalProtect and site-to-site), so design explicit proxy needs around full locations.

Service connections are IPSec tunnels from the customer's remote network or data center to Prisma Access; they carry corporate traffic and are required for private application access, while internet-bound traffic exits via the local egress at the compute location.

A remote network is a branch or data center attached by IPSec to Prisma Access; a service connection is the same tunnel type but used for corporate/private access from mobile users. Both terminate on the closest compute location.

Traffic steering for mobile users uses GlobalProtect app; for branches, use a remote network tunnel or an SD-WAN integration. Explicit proxy is an alternative for users who cannot run GlobalProtect.

Bandwidth license is sized by aggregate throughput per compute location, not per user; over-subscription is common, so size to peak aggregate egress plus headroom, and remember licensed bandwidth caps each location independently.

Prisma Access requires a Panorama or Strata Cloud Manager tenant; the management plane pushes config to the compute locations over the Prisma Access backbone, and the tenant must be reachable from Panorama on TCP 3978/443.

High availability: Prisma Access compute locations are redundant within a region; design for at least two regions or two compute locations when latency or regional failure tolerance is required, and use DNS-based GlobalProtect portal selection for failover.

For hybrid designs, decide where decryption happens: TLS decryption at the compute location adds latency and CPU; offload to a service connection edge or use selective decryption profiles for high-volume SaaS.

Onboarding order: activate the Prisma Access license, attach Panorama/Strata Cloud Manager, run the Prisma Access onboarding wizard, then commit; the wizard creates the service infrastructure and the default compute location.

GlobalProtect portal and gateway config lives in the Prisma Access template stack; the portal must be published with a public DNS name and a certificate trusted by endpoints; the gateway is auto-generated per compute location.

Service connection config requires: IKE gateway (pre-shared key or certificate), IPSec crypto profile, tunnel interface, and a static route; the remote side must match the same PSK and crypto profile exactly.

Use a dedicated service connection subnet per remote network; overlapping subnets between remote networks and Prisma Access cause routing loops and are rejected at commit.

Mobile user IP pools must not overlap with corporate subnets or with other pools; allocate a /24 or larger per compute location and keep pools out of RFC1918 ranges used internally.

Explicit proxy deployment requires a proxy server config, a proxy CA certificate for SSL inspection, and PAC file or manual proxy settings on endpoints; the proxy port must be allowed through the on-prem firewall.

For SD-WAN integration, use the Prisma Access SD-WAN plugin or a supported CPE; the branch device establishes the IPSec tunnel and advertises routes via BGP if dynamic routing is configured.

Commit flow: Panorama commit to Prisma Access pushes config to the cloud; validate with the Prisma Access status page and the service connection health check before declaring the deployment live.

Certificates: use a public CA for the GlobalProtect portal, and load the forward-trust and forward-untrust CA certificates on Panorama so the compute locations can perform SSL decryption.

Policy order: security rules are evaluated top-down; put specific allow rules above broad deny rules, and use the implicit deny at the bottom as the default. Zone-based rules apply because Prisma Access uses trust, untrust, and the GlobalProtect zone.

Use the Prisma Access predefined security profiles (antivirus, anti-spyware, vulnerability, URL filtering, WildFire) attached to allow rules; profiles are mandatory for the security subscription features to take effect.

SSL decryption policy is separate from security policy and is evaluated before security rules; exclude categories such as health and finance from decryption to avoid breaking pinned apps.

URL filtering uses the PAN-DB cloud; categories update dynamically, so a rule allowing 'business-and-economy' can change behavior over time; pin critical exceptions with custom URL categories.

For mobile users, apply policy based on user or user group via User-ID from GlobalProtect or Cloud Identity Engine; group-based rules require the identity source to be connected and synced.

Logging: Prisma Access forwards logs to the Cortex Data Lake; configure log settings on security rules, and use the Strata Logging Service for retention and search. Local logging on compute locations is limited.

Operations: use the Prisma Access status dashboard for compute location health, service connection status, and license usage; alerts can be configured for tunnel down and capacity thresholds.

Decryption and security profile changes should be staged: commit to a single compute location or use a canary rule first, then roll out globally to limit blast radius.

GlobalProtect won't connect: check portal DNS resolution, certificate validity, and that the endpoint can reach the portal on TCP 443; then check the gateway selection and the user's authentication (SAML/IdP) response.

Service connection down: verify IKE phase 1 (PSK, crypto profile, peer IP) then phase 2 (proxy IDs, subnets); a common cause is a mismatched proxy ID or an overlapping subnet.

Traffic not reaching Prisma Access: check the route on the remote network, the tunnel interface status, and the security policy on both sides; asymmetric routing across two tunnels causes drops.

Latency issues: use the Prisma Access compute location closest to the user; running decryption and WildFire inline adds latency, so measure with the built-in latency and path monitoring tools.

Throughput caps: the licensed bandwidth per compute location is a hard cap; if users see throttling, check the bandwidth dashboard and redistribute users across locations or upgrade the license.

Log analysis: search Strata Logging Service for the session; check the 'session end reason' field - 'policy-deny' means a security rule, 'decrypt-error' means a decryption profile issue.

Optimization: enable session offload for high-volume SaaS, use application-based rules instead of port-based, and tune security profiles to avoid scanning trusted internal traffic.

DNS and proxy issues: explicit proxy failures often come from a missing PAC file or a proxy CA not trusted on the endpoint; check the endpoint's proxy settings and the proxy server's certificate chain.