{"id":19974,"date":"2026-10-06T15:14:28","date_gmt":"2026-10-06T15:14:28","guid":{"rendered":"https:\/\/www.exam-labs.com\/blog\/?p=19974"},"modified":"2026-10-06T15:14:28","modified_gmt":"2026-10-06T15:14:28","slug":"palo-alto-networks-secops-pro-prisma-access-explicit-proxy","status":"publish","type":"post","link":"https:\/\/www.exam-labs.com\/blog\/palo-alto-networks-secops-pro-prisma-access-explicit-proxy","title":{"rendered":"Palo Alto Networks SecOps-Pro: Prisma Access Explicit Proxy"},"content":{"rendered":"

Prisma Access Explicit Proxy is a cloud Secure Web Gateway connection method that redirects proxy-aware HTTP and HTTPS traffic to Prisma Access using PAC files, forwarding profiles, GlobalProtect proxy mode, Prisma Agent transparent proxy, or supported proxy-chaining patterns. It is designed for organizations migrating from legacy explicit proxies or needing browser\/SaaS web traffic inspection without tunneling every protocol through GlobalProtect.<\/p>\n

Within Palo Alto Security Operations<\/a>, Explicit Proxy should be chosen from traffic scope and user experience: it secures web proxy traffic, while GlobalProtect tunnel mode protects all applications, ports, and protocols.<\/p>\n

The current Prisma Access documentation supports several hybrid designs, including Explicit Proxy for public web\/SaaS traffic combined with GlobalProtect or a third-party VPN for private applications.<\/p>\n

Explicit Proxy is not a full-device tunnel<\/h3>\n

PAC- or proxy-mode traffic is sent to the Prisma Access proxy endpoint rather than encapsulating all endpoint traffic.<\/p>\n

This makes Explicit Proxy a natural fit for HTTP\/HTTPS Secure Web Gateway migration.<\/p>\n

Applications that do not honor proxy settings, non-TCP protocols, or private access paths may need GlobalProtect, Prisma Agent, service connections, or another connectivity method.<\/p>\n

PAC files and forwarding profiles control traffic steering<\/h3>\n

Traditional deployments use a PAC file to decide which URLs go DIRECT and which use the Prisma Access proxy.<\/p>\n

Current forwarding profiles can simplify this by defining forwarding rules and supporting multiple PAC files; some forwarding-profile capabilities require specific Prisma Access\/dataplane versions and account-team enablement.<\/p>\n

Version-control PAC logic and test it like application code because one bad rule can bypass security or break critical sites.<\/p>\n

SAML authentication requires decryption for reliable identity state<\/h3>\n

Current configuration guidance says agentless SAML explicit proxy requires SSL decryption so Prisma Access can read the authentication-state cookie.<\/p>\n

Failing to enforce decryption can allow abuse of the explicit proxy as an open forwarding service in that architecture.<\/p>\n

Plan certificate trust, privacy exceptions, pinned applications, and troubleshooting before broad decryption rollout.<\/p>\n

User identification depends on the authentication mode<\/h3>\n

Prisma Access can identify proxy users through SAML\/Kerberos and supported trusted-proxy header approaches.<\/p>\n

Traffic logs then associate activity with the authenticated username or approved X-Authenticated-User data.<\/p>\n

Restrict trusted XAU source addresses tightly so an arbitrary client cannot forge identity by sending a header.<\/p>\n

Deploy in at least two regions for resilience<\/h3>\n

Palo Alto Networks’ current best practices recommend deploying Explicit Proxy in at least two regions.<\/p>\n

Also account for NAT concentration; current guidance recommends approximately one NAT IP per 500 mobile users when many users appear behind the same NAT device.<\/p>\n

Test failover and PAC\/proxy behavior when one region is unavailable so user traffic does not become stranded on a dead proxy address.<\/p>\n

Proxy-specific limitations should be known before migration<\/h3>\n

Current guidance notes that URL filtering actions such as continue\/override are not supported in Explicit Proxy and that decrypted HTTP\/2 flows are downgraded to HTTP\/1.<\/p>\n

Some applications require multiple source IPs per session or unusual protocols that do not behave well through an explicit proxy.<\/p>\n

Build a compatibility list during pilot and use tunnel\/direct exceptions only with a documented security rationale.<\/p>\n

Private application access can be layered onto Explicit Proxy<\/h3>\n

Current Prisma Access supports access to private\/data-center resources through service connections, ZTNA Connector, or Colo-Connect in supported versions, with private app access features depending on connection method and client version.<\/p>\n

Prisma Access Service Connections<\/a> and Prisma Access Remote Networks<\/a> provide the related connectivity context.<\/p>\n

Keep DNS and zone mappings aligned so proxy traffic reaches the correct private resource path.<\/p>\n

GlobalProtect can coexist with Explicit Proxy<\/h3>\n

One supported design uses GlobalProtect split tunnel for private applications while Explicit Proxy secures internet and external SaaS traffic.<\/p>\n

This reduces the traffic carried through the full VPN tunnel while preserving secure access to internal applications.<\/p>\n

Test route\/proxy precedence carefully because PAC exclusions and VPN split-tunnel rules can create accidental bypass or loops.<\/p>\n

Prisma Agent can add transparent proxy behavior<\/h3>\n

Current Prisma Agent can route supported TCP connections through Prisma Access explicit proxy based on forwarding profiles without relying on PAC files for every browser.<\/p>\n

UDP such as DNS is not supported by transparent proxy in the current documented mode.<\/p>\n

Use this method when broader application proxying is needed but still understand which protocols remain outside the proxy path.<\/p>\n

Logs should prove whether traffic was proxied, authenticated, decrypted, and allowed<\/h3>\n

Monitor proxy traffic logs, URL\/threat\/decryption events, user identity, region, policy rule, and failed authentication.<\/p>\n

Correlate issues with Strata Logging Service<\/a> so historical proxy evidence remains searchable and forwardable to the SOC.<\/p>\n

When users report one site failing, distinguish PAC steering, authentication, decryption, application compatibility, and security-policy block before changing the whole proxy design.<\/p>\n

Explicit Proxy succeeds when web traffic is intentionally scoped and the exceptions are understood<\/h3>\n

The mature deployment uses resilient regions, versioned forwarding logic, strong authentication and decryption, constrained trusted headers, compatibility testing, carefully designed private-access paths, and usable logs.<\/p>\n

An explicit proxy is effective when it gives the organization web\/SaaS control without pretending that every endpoint protocol actually passes through it.<\/p>\n

PAC design should minimize expensive DNS and wildcard logic. Complex PAC files are executed frequently on endpoints and can create latency or inconsistent behavior across browsers. Put simple exact\/suffix bypass rules first, centralize ownership, test with representative URLs, and avoid copying snippets from legacy proxies whose internal address assumptions no longer match Prisma Access.<\/p>\n

Authentication bootstrap paths must bypass the proxy correctly where required. Current best practices call out SAML, Cloud Identity Engine, and Authentication Cache Service URLs because forcing authentication traffic through a path that itself requires authentication can create loops. Keep these bypasses tightly scoped and test IdP failover.<\/p>\n

Certificate-decryption exceptions should be evidence-based. Financial, health, pinned, mutual-TLS, and privacy-sensitive sites may need no-decrypt rules, but broad categories can create large blind spots. Review decryption failures and application requirements, document exceptions, and periodically retest whether the original limitation still exists.<\/p>\n

Proxy chaining should be understood in both directions. A third-party proxy can forward to Prisma Access, and Prisma Access can participate in other chaining designs subject to supported configuration. Preserve client identity where possible and avoid loops where PAC or upstream routing sends the same request between proxies repeatedly.<\/p>\n

Explicit Proxy users behind shared NAT need source-IP planning because one public NAT address represents many concurrent sessions. Palo Alto Networks’ current guidance around roughly 500 users per NAT IP should be incorporated into branch or HQ egress design so authentication\/session scaling is not discovered under peak load.<\/p>\n

Browser\/session cookies are part of the authentication flow. Agentless SAML guidance requires cookies to function, and browser tracking\/privacy settings can affect the experience. Pilot modern browser policies and enterprise security extensions together so privacy-hardening does not accidentally break proxy authentication.<\/p>\n

URL filtering, App-ID, threat prevention, and decryption policy should be tuned with proxy context. Some controls behave differently when the connection is HTTP proxy traffic rather than a full tunnel. Build dashboards that distinguish Explicit Proxy traffic so policy changes can be tested without mixing GlobalProtect and branch traffic.<\/p>\n

Explicit Proxy should have a defined outage mode. Decide whether PAC falls back DIRECT, moves to a secondary Prisma Access location, or intentionally fails closed when the service is unreachable. Each choice has different security and business consequences; encode it deliberately in forwarding logic and incident runbooks.<\/p>\n

User support needs a small diagnostic playbook: confirm PAC\/forwarding profile, resolve proxy hostname, reach port 8080, complete SAML\/Kerberos, verify certificate trust\/decryption, inspect proxy\/traffic logs, and test the destination DIRECT versus proxied. This avoids broad policy changes when the problem is one local browser or DNS path.<\/p>\n

Migration from a legacy proxy should include policy parity and rationalization. Do not copy every old allowlist, bypass, category exception, and authentication workaround blindly. Use the move to remove obsolete exceptions, consolidate PAC files, modernize identity, and test whether Prisma Access native controls can replace legacy proxy-specific workarounds.<\/p>\n

Performance testing should include large downloads, streaming media, SaaS uploads, WebSockets, long-lived browser sessions, and high-latency users. A simple web-browsing pilot can miss applications whose proxy behavior differs under sustained traffic or connection reuse.<\/p>\n

Explicit Proxy DNS dependencies should be monitored. Endpoints must resolve the PAC location, proxy FQDN, IdP, and destinations correctly. Split DNS or captive network behavior can cause proxy failures that look like authentication or policy issues.<\/p>\n

Change control should treat PAC files and forwarding profiles as production routing policy. Peer-review updates, keep previous versions, and roll out to a pilot group first. One broad wildcard or DIRECT rule can create an organization-wide security bypass instantly.<\/p>\n

Audit should include who changed Explicit Proxy infrastructure, authentication, forwarding profiles, decryption, and private-app settings. These changes alter the inspection boundary, so they deserve the same visibility as firewall rulebase changes.<\/p>\n

Explicit Proxy security review should include bypass visibility. Track DIRECT decisions from PAC\/forwarding policy where possible and maintain a documented list of intentional bypass domains\/IPs. A growing bypass list is often a sign that compatibility exceptions are eroding the inspection boundary.<\/p>\n

Enterprise browser integrations should be tested separately from ordinary browser\/PAC deployments. Current Prisma Access supports third-party enterprise-browser integrations under specific version and coexistence limitations; verify those constraints before committing to a browser-security architecture that depends on multiple products.<\/p>\n","protected":false},"excerpt":{"rendered":"

Prisma Access Explicit Proxy is a cloud Secure Web Gateway connection method that redirects proxy-aware HTTP and HTTPS traffic to Prisma Access using PAC files, forwarding profiles, GlobalProtect proxy mode, Prisma Agent transparent proxy, or supported proxy-chaining patterns. It is designed for organizations migrating from legacy explicit proxies or needing browser\/SaaS web traffic inspection without […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19974","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t