Global employees accessing internet using Cloud SWG via WSS Agents.
After deploying WSS Agent to users in Egypt, no one could connect to Cloud SWG services.
WSS Agent tunnel failed to establish to all nearest data centers, but also remote data centers using dpOverride that corporate users in other locations could access without issues.
Tethering the same WSS Agent host to some other ISPs in the region allowed the tunnel to establish.
WSS Agent.
ISPs intercepting traffic.
ISPs intercepting traffic and blocking protocols it cannot understand.
Work with local ISPs to get permission to tunnel traffic into Cloud SWG destination IP addresses.
In scenario below, ISP was doing protocol detection on initial payload exchanged from client side, not recognising the protocol and not forwarding requests upstream. As a result, the Cloud SWG tunnel endpoint never returned the full authentication challenge needed to establish the tunnel.
Symdiag PCAPs give key information regarding the flow. What we see from the PCAPs is the following:
- User generates a CTC request and gets list of nearest data centers
- User tried to access nearest data center using UDP port 443 and fails to complete the handshake
- User switches to TCP transport and then tries to establish a tunnel to each of the returned data center VIPs
- after failing to connect to all 3 returned data centers, the WSS Agent errors out.
Of more importance is the initial application traffic via the WSS Agent. From screenshot below: