On premise users access internet sites via Cloud SWG using the IPSEC access method.
Velo Edge devices are used to route all internal traffic over IPSEC into Cloud SWG.
Users on Windows hosts running WSS Agent on premise should go PASSIVE but are tunneling the traffic into Cloud SWG directly.
CTC communication on the WSS Agent host confirms that we are ACTIVE, and the CTC response refers to an IP address that is not the egress IP address of that IPSEC location (as shown below)
[11:04:40]: CTC Response ACTIVE(GEOIP) - egress: #.#.#.# GINDE-168.149.182.170 GINMU-148.64.4.170 geolocation: IN WB Kolkata
Velo Edge.
WSS Agent.
Cloud SWG.
CTC requests configured to go DIRECT and not via IPSEC tunnel, and hence no match to an IPSEC (or any other Cloud SWG Location) is found to trigger a PASSIVE CTC response.
Make sure we
When the CTC request is sent into Cloud SWG, there is some logic in the Cloud SWG policy to handle this traffic differently where the proxy will inject the location ID into the HTTP request forwarded to the CTC service). Assuming this location ID matches any of our location IDs in the ATM PASSIVE list, then the agent will not go ACTIVE.
The Velo Edge has a business policy that routes WSS Agent traffic directly into the Velo POP to avoid the WSS agent tunnelled traffic going into the IPSEC tunnel (not supported). This business policy also included the CTC traffic, so the egress IP addresses reported in the CTC response log entry was from the Velo POP and not the customer edge.
Since the Velo POP is not a predefined location, we never found a matching location and hence never went PASSIVE. An option would have been to add the Velo POP IP address into their Cloud SWG location configuration, but this is not allowed as the customer did not own this egress IP address.