First user in newly provisioned Cloud SWG tenant connecting via WSS Agent on Windows.
Block notification service connectivity failing from WSS Agent.
Tunnel comes up without issues but user always sees the WSSNS status show up as 'Failed'.
WSS Agent diagnostic logs show following errors at time of problem:
[02-20-2023 17:43:59 (UTC+1:00)]: WSS Channel connecting - Tunnel#30(<DOMAIN>\<USER>)[10]
[02-20-2023 17:43:59 (UTC+1:00)]: WebSocket exception - Tunnel#30(<DOMAIN>\<USER>)[10]: Underlying Transport Error
[02-20-2023 17:44:25 (UTC+1:00)]: WebSocket exception - Tunnel#30(<DOMAIN>\<USER>)[10]: TLS handshake failed
[02-20-2023 17:44:50 (UTC+1:00)]: WebSocket exception - Tunnel#30(<DOMAIN>\<USER>)[10]: TLS handshake failed
[02-20-2023 17:45:06 (UTC+1:00)]: The WSSNS Service could not be contacted. Another attempt will be made the next time WSS Agent connects to the service
Cloud SWG configured using UPE.
WSS Agent.
Policy blocking requests destined to notification.symcwss.cloud for user.
Make sure that requests destined for domain notification.symcwss.cloud are allowed for all users.
Cloud SWG Portal managed tenants have default policy allowing this, but UPE based policies need to make sure it is allowed.
The block notification service feature of WSS Agent requires a Web socket connection from the WSS Agent to notification.symcwss.cloud via the tunnel. By default all traffic to this destination should go through the tunnel, and PAC files pushed down to the WSS Agent host should reflect this. Assuming the traffic for this site comes into the tunnel and up to the Cloud Proxy, any policies executed there should be allowed for this domain.