WSS Agent does not go into passive mode
search cancel

WSS Agent does not go into passive mode

book

Article ID: 168621

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

The organization has an on-premises Symantec Edge Secure Web Gateway (Edge SWG, formerly ProxySG) that protects the corporate network. To enforce the local policies while users are connected to the corporate network, WSS Agent (WSSA) must go into a passive mode. Passive mode ensures that the on-premise policies take effect on all user devices.

The following log entry indicates where the connection is forcibly closed by the remote host.

<16>[05-24-2016 10:35:05 (UTC+5:30)]: Tunnel error on tunnel(non-interactive-user): (10054) An existing connection was forcibly closed by the remote host

The host does not mean only the data center, but includes intermediate devices such as firewalls, proxies, and so on. If the proxy does not allow the connection to the data center, the WSSA won't be able to establish the connection. The agent is unable to enter passive mode in this case.

Environment

Environment protected with Edge SWG, WSSA on laptops for remote users

Cause

WSSA attempts to establish a connection to  ctc.threatpulse.com, and portal.threatpulse.com, which it must do to determine whether it is on a protected network. When WSSA detects that it is on a protected network, it goes into passive mode automatically.

Resolution

Enforcing passive mode on WSSA

Log in to the Cloud SWG portal.

Create a passive agent rule in the Agent Traffic Manager (ATM) connectivity section that specifies the public egress IP address for the corporate network using the following steps:

    1. Go to "Connectivity > Agent Traffic Manager" and select "Passive Agent Rules".  If you have a rule that contains a "Passive Location List", click on the Edit button.  Otherwise, click on the "+Add Rule" button.
    2. In the Conditions section, click on the Passive Location List.  Add any network locations you may have recently made and want agent to go passive, to the list.  Click on the Save button.  Click on the Save Rule button.
      • Alternate method:  If you do not have a Passive Location List, click on the "+ Add Locations / Egress IPs" button in the Conditions > Sources section.
      • Add the network locations or egress IPs.  If the network location is not defined, you can add an egress IP address to the list.
      • Click on the Save button.  Make sure the verdict is the passive verdict.
      • Click on Add Rule.
    3. The new or modified rule will be inactive.  Press the Activate Policy button in the upper right hand corner of the page to make the policy active.
    4. Ensure that:
      • Authentication on the on-premises Edge SWG is disabled for: client.threatpulse.net, ctc.threatpulse.com and portal.threatpulse.com
      • SSL interception is disabled for: client.threatpulse.net, ctc.threatpulse.com and portal.threatpulse.com
      • Traffic is allowed on: client.threatpulse.net, ctc.threatpulse.com and portal.threatpulse.com
      • Intermediate devices are checked. If the proxy or firewall does not allow the connection to data center, WSSA cannot detect itself from the portal.
      • Add the Cloud SWG (formerly known as WSS) ingress and egress IP addresses to the ALLOW rule of the proxy or firewall.

NOTE:  Prior to ATM, when a network location was created, any agents connecting from that network location went into a passive state.  When ATM became available to all Cloud SWG customers in late November 2024, the ability to cause agents to go passive when egressing out of a defined network location no longer occurred.  To preserve the previous behavior, existing network locations were migrated to the passive location list within ATM, but any new network locations were not automatically added to the passive agent list.  Therefore, when creating a new network location, if you need to have agents go passive, you also need to add the newly created network location added to the passive location list and activate policy.