WSS agents not connecting to correct localization zone and as a result GEO locating incorrectly
search cancel

WSS agents not connecting to correct localization zone and as a result GEO locating incorrectly

book

Article ID: 231516

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

WSS agent active and running on Windows workstations

Users connecting from locations that have localization zones active - a localization zone provides an improved user experience by localizing content requests for countries where there is no WSS compute POP.

Users in Turkey connecting to Swiss GCHZU1 datacenter and not the expected GTRAN11 datacenter location. Those clients should be connected to Frankfurt DC to use Turkey vPOP IP as per the WSS IP address KB article.

Users trying to access certain local sites blocked as requests coming from a non local IP address (and ACLs only allowing local users)

Users seeing certain web sites rendered with non local content e.g. seeing German instead of Turkish.  

 

 

Environment

WSS Agent 7.4.2+ - required to support localization zones

WSS agent versions on both Windows and MAC will exhibit this behaviour

Cause

Client Firewall Service (CFS) license enabled on this tenant

Any tenant running the CFS license will be connected to a prime data center where the CFS modules are active.

Resolution

Two options exist:

1. disable the CFS license if not in use. In this scenario, we had a trial CFS license that was not being used and were able to remove it without any user impact.

2. Use dpOverride WSS agent parameter to bypass CTC responses and connect directly to our Frankfurt VIP (199.247.38.164).

This requires the user to run CMD in admin mode on the Windows workstation and doing the following:

C:\Users\test>cd "\Program Files\Symantec\WSS Agent"
C:\Program Files\Symantec\WSS Agent>wssad.exe -p dpOverride=199.247.38.164

When the changes are pushed out, reconnect the WSS agent.

Additional Information

CFS is planned to be pushed out to all sites (prime and non prime) in the first half of 2022 and workaround no longer needed after this is complete.