ZTNA application access fails due to PAC file routing conflict with WSS Agent
search cancel

ZTNA application access fails due to PAC file routing conflict with WSS Agent

book

Article ID: 446051

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

When using WSS Agent in selective intercept mode alongside a manual Proxy Auto-Configuration (PAC) file, users may be unable to access private applications configured via ZTNA. This occurs even if the WSS Agent is active and the domain is correctly defined in the ZTNA portal.

  • Private ZTNA applications fail to load or show "Site cannot be reached."
  • The domain resolves to a ZTNA internal IP (e.g., 198.18.x.x), but traffic is still sent to the standard web proxy.
  • Connection succeeds if proxy settings are disabled.

Environment

Product: Cloud Secure Web Gateway (Cloud SWG)

Component: WSS Agent (WSSA) / ESA Agent with Web Security

Feature: Zero Trust Network Access (ZTNA)

Configuration: PAC file or manual proxy is in use

Cause

If the PAC file contains a rule that sends the ZTNA domain traffic to proxy.threatpulse.net or ep.threatpulse.net, the Agent forwards the traffic to the web proxy instead of intercepting it and route to the ZTNA service.

Resolution

To allow the WSS Agent / ESA Agent to intercept ZTNA segment custom domain application traffic, the PAC file must return DIRECT for the specific ZTNA application domains.

  1. Locate the PAC file used by the affected clients.
  2. Add a bypass rule at the top of the FindProxyForURL function for the ZTNA application domain:
     
    if (shExpMatch(host, '*.example.net')) {
    return "DIRECT";
    }
  3. Save and host the updated PAC file.
  4. Restart the browser or reconnect the WSS Agent on the client machine then verify the ZTNA application access.