Users running WSS agent unable to connect to WebexEx meeting

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

WSS agent used to access internet via Cloud SWG.

WSS agent users in Office are unable to connect to Webex meetings. As soon as they click Join Meeting button, they see infinite "connecting" message.

All Webex traffic is bypassed from Cloud SWG, and is technically not going into Cloud SWG.

Joining meeting from home network on same laptop works fine.

Uninstalling WSS Agent from one of the impacted machine allowed office users to work fine - users would egress to internet via on-prem proxies using that route and not same path as non proxy traffic!

 

Environment

Users not egressing to internet directly for traffic from WSS Agents - GRE connection over Cisco router from local office to internet egress point.

Non agent traffic sent to local proxy that egresses directly to internet.

Egressing directly has no issues.

Cause

Internal Cisco router configured with MTU that caused large packets coming into WSS agent host from Webex servers to be dropped.

Resolution

Reduce IP MTU size of local Cisco router 

Office site uses GRE to backhaul traffic to corporate data center before egressing out to internet via Cloud SWG. With the advertised MTU size, large payloads coming back from the Webex server would be blocked by an intermediate router and not make it to the WSS agent host. These large payloads included SSL cert information, which in turns caused the SSL handshake to fail. To address the issue, we dropped the MTU from 1476 to 1400. This means that the TCP MSS sent out with TCP SYN requests was smaller, which Webex used to reduce size of payload and bypass any MTU issues with intermediate routers.

interface Tunnel2
description WAN Internet VPN from BLA to SYD
ip unnumbered Loopback1
ip mtu 1476   <<< Reduce to 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0.10
tunnel destination #.#.#.#

Additional Information

As you can see in the captures below, the working case (Guest wifi link going through onprem proxy) shows client proposed 1460 of MSS in TCP SYN, and the the server side sends back payloads that we can accept taking the network pth 

In the non-working case, taking a different network path, we also advertise an MSS of 1460 in the TCP SYN but you can see that we keep re-requesting TCP segments from the server side.

Reducing the advertised MSS means that the server will send smaller payloads back to the client, and no intermediate devices end up blocking these packets.  

 

// Working PCAPs from WSS agent workstation

// Non working machine