Geolocation based rules not applying correctly to WSS users

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing Web via WSS using multiple access method including IPSEC, explicit and agents.

GEO and risk license enabled on tenant allowing admin to apply GEO location based rules

A geolocation block from requests initiating from Country X for any destinations/sites need to be applied within the company due to local regulations. The following summarises the rule in place:

- Source: Geolocation (Country X)
- Destination: Any
- Limit: Any
- Verdict: Block

Users from country X are allowed to access resources through WSS.

Environment

WSS with multiple access methods

GEO restrictions

Cause

GEO based policies will only work with access methods that show the public, non RFC1918, IP addresses

Resolution

Make sure that users coming into WSS from Country X use an access method that shows their public IP addresses. With IPSEC access method, the inbound requests into the Proxy originate from non routable RFC1918 IP addresses, which our GEO based policies cannot resolve to a specific country.

In the above example, corporate traffic from country X was being backhauled into an IPSEC router at a different location and into WSS - internal routing should have blocked that at source.

If the GEO policy blocks access to specific rather than all sites, then switch access methods from the Country X and use WSS agents on hosts there.

Additional Information

Here are some example HTTP access log entries for key access methods, showing the ingress IP address that the proxy sees with each request:

// IPSEC access method - shows RFC1918 IP address that WSS cannot use to determine source country

2024-05-02 08:37:08 "DP1-GROBU1_proxysg1" 5 10.149.210.62 Unauthenticated%20User - - OBSERVED "Technology/Internet" - 200 TCP_NC_MISS GET application/octet-stream http example.com 80 / - - "Microsoft-Delivery-Optimization/10.0" 168.149.148.1 1911 313 - - - - 465048 "Example Location" firewall_vpn "Microsoft Update" "Update Software" #.#.#.# "United Kingdom" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - #.#.#.# - - - - - - - - - - - - - - - - - - - - - aaa-bbb-ccc 168.149.148.1 168.149.148.1 "RO" "Romania"

// Explicit access method - includes (masked) public IP address that WSS can use to determine source country

2024-05-02 08:46:03 "DP1-GROBU1_proxysg1" 1 #.#.#.# - - user1@example.com DENIED "Web Infrastructure" - 200 TCP_DENIED GET - http list.bluecoat.com 80 /ClientLatencyMon.htm - htm "PycURL/7.43.0 libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3" 192.168.1.84 16054 221 - - - - 467465 "explicit-gdefr1-gdefr11-gdefr2-gchzu1-g" explicit_proxy "-" "-" 168.149.132.101 "Belgium" - - - - - none - - - - none - - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - - - - - - - - - - - - - - - - - - - - - - - 235c50b82132299b-0000000019eb321d-00000000629878cb - - "Invalid" "Invalid"

// WSS Agent access method - includes (masked) public IP address that WSS can use to determine source country

2024-05-02 08:47:11 "DP1-GROBU1_proxysg1" 42 #.#.#.# user1@example.com - - OBSERVED "Finance" - 0 TUNNELED unknown - ssl example.com 443 / - - - 168.149.148.1 11582 6794 - - - - 0 "client" client_connector "-" "-" #.#.#.# "South Africa" CERT_VALID none - - TLSv1.3 TLS_AES_128_GCM_SHA256 128 example.com "Finance" TLSv1.3 TLS_AES_128_GCM_SHA256 128 - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - #.#.#.# "South Africa" - "Montenegro" 2 2 unified-agent architecture=x86_64%20name=Windows%2010%20Enterprise%20version=10.0.19044 4.10.3.225009 #.#.#.# aaa-bbb-ccd ExampleHost - - - - - - - - - #:#:#:#:#:#:#:# ccc-bbb-aaa #.#.#.# #.#.#.# "RO" "Romania"