WSS Agent connection failure when adding public DNS server IP addresses to host
Article ID: 447301
Updated On:
Products
Issue/Introduction
Users successfully accessing internet sites via Cloud SWG using WSS Agent on Windows.
A new subset of WSS Agent have been added via a company merge, and these hosts point to external DNS servers (such as 8.8.8.8 and 9.9.9.9), unlike all other hosts using the service.
When utilizing the WSS Agent alongside a active VPN (e.g., Cisco AnyConnect) and external DNS servers, all works fine.
When the VPN is disconnected, WSS Agent fails to connect and not internet access is possible.
WSS Agent diagnostic logs never show any of the expected CTC response information.
If there is a previously cached response on the host, the tunnel will come up as it has access to the Cloud SWG VIP IP addresses.
Environment
Cloud SWG.
Public DNS server defined on Windows hosts.
Web and DNS interception enabled in ATM.
ATM DNS proxy rules
WSS Agent setup with Fail closed (Fail behaviour set to 'Block all traffic')
Cause
This issue occurs due to a DNS interception limitation. When WSS interception is active, UDP port 53 traffic to external DNS servers may be blocked if the tunnel is not yet authenticated or if explicit bypasses for those DNS servers are not present in the Agent Traffic Manager (ATM).
Resolution
To resolve the issue in this type of environment with public DNS servers defined on the host, DNS and Web proxy interception enabled and Fail behaviour set to 'Block all traffic', an explicit bypass must be configured for the external DNS servers within the WSS portal:
- Navigate to Connectivity > Agent Traffic Manager.
- Locate the Traffic Bypass rules.
- Add the specific external DNS IP addresses (e.g., 8.8.8.8 and 9.9.9.9) to the IP bypass list bypass list. If you have other public DNS servers, we can also add all the DNS server IP addresses, or add an exception for destination -> custom ports and add UDP 53 so that traffic destined for this UDP port is not to be sent into the tunnel.
- Note: Bypassing these IPs ensures that DNS queries for the VPN and WSS CTC resolution can reach the external resolvers without being intercepted by the WSS logic during the pre-authentication phase.
Additional Information
Symdiag taken at time of the issue when the Agent was restarted, no DNS requests for ctc.threatpulse.com or TCP connections to the same CTC site were visible.
Diagnostic logs simply showed CTC errors:
[07-01-2026 12:47:02 (UTC+1:00)]: WSS Agent has closed the connection. A new connection attempt will be made.
[07-01-2026 12:47:08 (UTC+1:00)]: CTC failed (ec: 12002 - The operation timed out)
[07-01-2026 12:47:15 (UTC+1:00)]: CTC failed (ec: 12007 - The server name or address could not be resolved)
[07-01-2026 12:47:28 (UTC+1:00)]: CTC failed (ec: 12002 - The operation timed out)
[07-01-2026 12:47:33 (UTC+1:00)]: CTC failed (ec: 12007 - The server name or address could not be resolved)
[07-01-2026 12:47:39 (UTC+1:00)]: CTC failed (ec: 12007 - The server name or address could not be resolved)
[07-01-2026 12:47:45 (UTC+1:00)]: Attempting direct CTC request after 5 failures
[07-01-2026 12:47:45 (UTC+1:00)]: CTC failed (ec: 12007 - The server name or address could not be resolved)
[07-01-2026 12:47:56 (UTC+1:00)]: CTC failed (ec: 12002 - The operation timed out)
[07-01-2026 12:47:56 (UTC+1:00)]: CTC: trying to use cached CL after 6 failures
[07-01-2026 12:47:56 (UTC+1:00)]: CTC: using the connect list cached in memory
Internal debug logs from the Agent showed outbound DNS requests were dropped as the driver was in blocked mode (fail closed).
Feedback
