Users accessing internal Web applications via ZTNA (Web and not segment applications).
These same users access internet sites via Cloud SWG using WSS Agent access methods.
Web application defined with a conditional policy for managed devices referencing WSS as shown below:
When a user hits this ZTNA Web application via Cloud SWG, the policy appears to fail and ZTNA responds with a 403 instead of the Web page. This only started happening late November 2025.
If we disable the Web access policy WSS authentication check above, then all works fine and user sees web application.
When troubleshooting, we could see the impacted users were connected to Copenhagen, who's egress IP address range changed recently (along with many other sites).
Th forensic logs also reported the country code as United States.
Following the migration of public IP addresses for WSS, we have experienced significant issues with ZTNA. We are encountering challenges with the geolocation of the new addresses, as some of them are being identified as US-based even if we go out through the Copenhagen location zone.
Additionally, there is a condition in ZTNA that requires traffic to originate from WSS - this no longer works after the update, likely because the addresses have not been correctly updated in ZTNA.
ZTNA Web application.
ZTNA Web policy enabled with WSS authentication condition (which verifies that the egress IP address of the inbound request be a Cloud SWG IP address).
The ZTNA Cloud SWG / WSS IP address database had not been updated to include these new Copenhagen IP address range recently added to the service (a sample WSS egress IP address was 199.247.32.37 shown above and documented in the Cloud SWG IP address KB referenced above).
Updated all new Cloud SWG/WSS egress IP addresses on the ZTNA database, and resolved an internal API problem retrieving the IP address updates.
No changes needed by the ZTNA admin.