WSS Agent fail over always uses TCP transport instead of UDP

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

When the WSS Agent cannot communicate with the first data center returned in the CTC response, it always connects to the subsequent data center using TCP.

WSS Agent behaves in the following manner when the CTC data center VIPs are returned:

- Try and connect to Primary POP using UDP initially and then TCP.

- If the above communication fails, try the secondary POP returned but with TCP only

- If the above communication fails and a tertiary POP is returned with the CTC response, try the tertiary POP with TCP only

WSS Agent logs confirm this behaviour as shown below:

[07-25-2022 08:06:09 (UTC+1:00)]: WSS Agent has closed the connection. A new connection attempt will be made.
[07-25-2022 08:07:59 (UTC+1:00)]: CTC Response: ACTIVE(GEOIP)  GGBLO-148.64.9.164  GGBDO-170.176.242.164  
[07-25-2022 08:08:00 (UTC+1:00)]: Attempting to connect to GGBLO via UDP
[07-25-2022 08:08:05 (UTC+1:00)]: UDP Connection failed (26), will attempt TCP on the same DP
[07-25-2022 08:08:06 (UTC+1:00)]: Attempting to connect to GGBLO via TCP
[07-25-2022 08:08:17 (UTC+1:00)]: Connection failed (995) for GGBLO, will use next DP in connectList
[07-25-2022 08:08:18 (UTC+1:00)]: Attempting to connect to GGBDO via TCP
[07-25-2022 08:08:18 (UTC+1:00)]: CA Tunnel#4(non-interactive-user) connecting to 170.176.242.164
[07-25-2022 08:08:18 (UTC+1:00)]: CA Tunnel#4(non-interactive-user): status:SUCCESS-authorized
[07-25-2022 08:08:18 (UTC+1:00)]: Tunnel#4(non-interactive-user) Connected: CC: 170.176.242.164(GGBDO-TCP), Nat IP: 10.232.192.165
[07-25-2022 08:08:18 (UTC+1:00)]: Connection to WSS successful
[07-25-2022 08:08:18 (UTC+1:00)]: CA Tunnel#5(DOMAIN\user) connecting to 170.176.242.164
[07-25-2022 08:08:19 (UTC+1:00)]: Tunnel#5(DOMAIN\user) Connected: CC: 170.176.242.164(GGBDO-TCP), Nat IP: 10.241.64.85

Why do we not use the UDP transport with the secondary and tertiary POPs, as we do with the primary?

 

Environment

WSS Agent

Cause

Working as designed.

Resolution

When the WSS Agent cannot access the primary VIP and we failover to second VIP, the agent will always uses TCP at transport layer

This is done with performance in mind. When communication to the primary POP has failed and needs to try the secondary POP, the agent has already spent 30 seconds trying to connect to the first datapod. Instead of going through the same operation on the secondary POP, and knowing that some firewalls block QUIC traffic on UDP 443, we switch to TCP to try and connect as quickly as possible. This reduces the time that the user is unprotected, allowing the tunnel to come up quickly.