WSS agent fails to go passive when connecting via IPSEC firewall
search cancel

WSS agent fails to go passive when connecting via IPSEC firewall

book

Article ID: 424316

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

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

 

Environment

Velo Edge.

WSS Agent.

Cloud SWG.

Cause

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.

Resolution

Make sure we

  • send the CTC request into Cloud SWG (currently goes out the Velo Edge device directly into Velo POP) by changing the business policy on Velo for the ctc.threatpulse.com domain AND
  • make sure the ATM passive location includes the IPSEC tunnel location

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.

Additional Information

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.