TLS/WebSocket failing after implementing DP Override to Amsterdam POP

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Having investigated the logs/capture within the uploaded symdiag for our particular case, see the findings below.

What actually happened (from the WSSA log)

1. Wrong DP IP on the first tries → connect refused

   • The customer forced a DP override to …*.164 - which is not the DP the Cloud Traffic Controller (CTC) offered. CTC advertised GNLAM = 98.158.252.170 and GDEFR = 199.247.38.170. When you overrode to 199.247.38.164 the tunnel failed with UDP timeout (ec:26) and TCP actively refused (ec:10061), exactly as would be seen in the logs. 

2. Using the correct Amsterdam DP → tunnel comes up, but the WebSocket/TLS channel fails

   • When you override to 98.158.252.170 (Amsterdam) the agent connects successfully over UDP 443:
     “Tunnel#5 … connected to concentrator: 98.158.252.170 (OVR-UDP) … Connection to WSS successful”.
     Immediately after, the WSS Channel (WebSocket over TLS) fails with “Underlying Transport Error / TLS handshake failed”, then:
     “The WSSNS Service could not be contacted”. This sequence matches a policy block of the notification WebSocket endpoint.

Ref.: Cloud SWG (formerly WSS) Ingress and Egress IP addresses

Environment

WSSA (Windows)

Cause

Why the TLS/WebSocket is failing

The Tech. Article with the URL below documents this exact pattern (tunnel OK, then repeated “WebSocket … TLS handshake failed” + “WSSNS Service could not be contacted”) when tenant policy blocks the agent’s notification service domain notification.symcwss.cloud (the WebSocket runs inside the tunnel). Resolution is to explicitly allow that domain in policy (UPE customers often hit this).

Ref.: Cannot connect to WSSNS service with newly provisioned Cloud SWG tenant

Root cause(s)

• Primary: Initial DP override used the wrong IP (.164) - not the Amsterdam concentrator CTC advertised (.170) - causing timeout/refused. After switching to .170 the tunnel is fine. 

• Secondary: Tenant policy is blocking the in-tunnel WebSocket to notification.symcwss.cloud, producing the TLS handshake failed and WSSNS errors. 
  
  Ref.: Cannot connect to WSSNS service with newly provisioned Cloud SWG tenant

• Not a factor: Tamper Protection (already disabled).

Resolution

Fix / next steps

1. Use the correct DP IP for Amsterdam

   • Per the log, 98.158.252.170 is the correct GNLAM concentrator during your test. Re-set the override accordingly and re-test:
     wssad.exe -p dpOverride=98.158.252.170

   • When finished, remove the override so CTC can steer normally:
     wssad.exe -e dpOverride

   • Reference (and note the Tamper Protection prerequisite for setting dpOverride):
     
     Ref.: How to configure WSSA to manually connect to a Data Center 

2. Allow the notification WebSocket endpoint in Cloud SWG policy

   • Add an allow rule for notification.symcwss.cloud for all users (UPE-based tenants especially). Then reconnect the agent and confirm WSSNS goes OK. 
     
     Ref.: Cannot connect to WSSNS service with newly provisioned Cloud SWG tenant
     
     If you manage Cloud SWG with UPE (Unified Policy Editor)

     Create a high-priority Allow rule (place it above broad blocks):

     Rule name: Allow WSSA Notification Service
     Who: Any (or your WSSA users group)
     What (Destination):

     • URL Host equals notification.symcwss.cloud
       (You can also add symcwss.cloud with a URL Domain equals condition if you prefer belt-and-braces, but notification.symcwss.cloud is the key.)
       Service: Any (or HTTPS)
       Action: Allow

     The Tech. Article with the URL below explicitly notes that UPE tenants must allow this domain for all users to avoid the “WSSNS Service could not be contacted” / TLS handshake failures.
     
     Ref.: Cannot connect to WSSNS service with newly provisioned Cloud SWG tenant

     If you manage Cloud SWG with the Portal Policy (classic)

     Most portal-managed tenants already allow this by default. If you have custom denies, add an explicit Allow exception:

     1. Go to Policy → Content Filtering.

     2. In Group A – Request-based (evaluated before contacting the server):

        • Click Add Rule.

        • Sources: Any (or the group of WSSA users, if you want to scope it).

        • Destinations: Add notification.symcwss.cloud.

        • Content and Limits: Any.

        • Verdict: Allow.

     3. Move this rule to the top of Group A so it’s evaluated before any blocks.

     4. Save and Activate Policy.

     If you were testing with DP override, remember the supported commands to set/remove it after your policy change.
     
     Ref.: Cannot connect to WSSNS service with newly provisioned Cloud SWG tenant
     
     

     Why in Group A?

     • Group A rules are checked before the request is sent to the site.

     • This ensures the WSSA agent can reach the notification service without hitting category/domain blocks.

     Once you apply it, reconnect the WSSA agent and run the in-tunnel PCAP again. This time you should see a TLS ClientHello to notification.symcwss.cloud and no WSSNS/TLS errors in the logs.

     Optional: CPL snippet (for advanced / hybrid cases)

     If you use CPL (e.g., advanced policy or on-prem SG in front of Cloud SWG), this minimal allow works:

      

     <Proxy>

     url.domain=notification.symcwss.cloud allow

     Place it before any broad deny rules.

     Notes & verification

     • No special WebSocket object is needed—just allowing the destination domain is enough; the WebSocket runs over TLS to that host.

     • After policy update, reconnect WSSA and confirm the log no longer shows “TLS handshake failed” / “WSSNS Service could not be contacted.”

     • If you still see issues, check that outbound UDP 443 (and TCP 443 fallback) to the selected DP is permitted, but the critical bit is the allow for notification.symcwss.cloud.

3. Connectivity hygiene checks (quick)

   • Ensure UDP 443 (and TCP 443 fallback) to the chosen DP IP are allowed egress.

   • Avoid routing WSSA over another VPN client; WSSA should egress direct to Internet.
     
     Ref.:VPN client configuration with WSSA or SEP tunnel mode

How to verify (with your captures)

• In the In-Tunnel PCAP (the agent created), look for a TLS ClientHello to an SNI of notification.symcwss.cloud, followed by a TLS alert or reset - that confirms the policy block. (Your log already shows the timing and the WSSNS failure.). See the sample outputs from checks on the generated In-Tunnel PCAP within the uploaded symdiag.
  
  
  
  
  
  
  

Explanation:

• tls.handshake.type == 1 → matches ClientHello messages.

• tls.handshake.extensions_server_name → extracts the SNI field.

• The == "notification.symcwss.cloud" part limits results to that exact hostname.

From the screenshots, the filter:

tls.handshake.type == 1 && tls.handshake.extensions_server_name == "notification.symcwss.cloud"

returns no results, which means:

• In this in-tunnel capture, the WSSA agent never even attempted a TLS handshake to notification.symcwss.cloud.

• That aligns with the WSSA logs showing the WebSocket/TLS connection to WSSNS failing almost immediately - the connection was likely blocked before the handshake began, so it never appears in the PCAP.

When we ran the broader filter:

tls.handshake.type == 1

we did see ClientHello messages for other hosts (pod.threatpulse.com, knowledge.broadcom.com, whatismyipaddress.com, etc.), but not for the notification service.

What this means for troubleshooting:

• The absence of the SNI in the capture suggests either a policy block (so the client never tries), or the process is failing internally before it can initiate the TLS handshake.

• Allowing notification.symcwss.cloud in policy is still the correct step - once allowed, you should see the handshake appear in the in-tunnel PCAP.

Additional Information

IP 98.158.252.170 is publicly used for the GNLAM POP, and for a DP Override, CTC presents this IP, even though it isn't included in the KB Article: Cloud SWG (formerly WSS) Ingress and Egress IP addresses.