MacOS WSS Agent users get blank login page instead of SAML IDP login page

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

WSS Agent 8.1.2 running on MacOS 12 where authentication into Cloud SWG is done via SAML.

Users accessing Cloud SWG from outside corporate network work fine and get the IDP login page popping up when agent is started.

Users on internal network get a popup page without any error message or challenge for credentials as shown below:

On premise users get a PAC file downloaded to the host that sends almost all internet traffic into the WSS via ep.thtreatpulse.net (199.19.250.205:80) with exception of some internal hosts and RFC1918, which go direct out their network.

On premise SAML IDP server is accessed via public IP address when users are remote, and via an internal IP address when users are on premise.

Environment

WSS Agent 8.x on MacOS 12.5.

On premise SAML IDP server.

Cause

Request to pod.threatpulse.com triggering start of SAML based authentication going out public interface and not in-tunnel interface.

Resolution

Remove the following RFC1918 and localhost/autoconfig ranges from the WSS bypass list as no traffic is sent into WSS for these ranges anyway.

10.0.0.0/8
172.16.0.0/16
192.168.0.0/16
169.254.0.0/16 (autoconfig)
127.0.0.0/24 (localhost)

NOTE: With PAC files and using SAML with WSSA,it is imperative that traffic destined pod.threatpulse.com and *.threatpulse.net goes "DIRECT" in the PAC file so that the traffic will properly be sent through the tunnel.

When we bypass these IP addresses, and our DNS server is listening on an RFC1918 IP address, DNS snooping is not happening and we sent request out the public interface instead of tunnel as shown below:

Any DNS server listening on any of these RFC1918 IP address ranges will be bypassed and exempted from snooping. In doing that, IPv6 blocking, domain bypass, and SAML authentication will all be impacted.

After removing the RFC1918 IP addresses from WSS bypass list, the WSS agent DNS snooper picked up the DNS requests for pod.threatpulse.com and saml.threatpulse.net and sent the requests into the tunnel allowing the SAML IDP login page to appear.

Additional Information

Following set of data showed how we identified source of problem:

Grabbed Symdiag when tunnel up but get blank page in WebKit popup (no error)
WSSA logs shows auth request starts at 14:43:37

[2022-Sep-26 14:42:26 (UTC+2:00)]: Tracing has been enabled
[2022-Sep-26 14:42:27 (UTC+2:00)]: Started In-Tunnel PCAP to /tmp/wssa-diag.5080/archive/WssaInTunnelTrace.pcap
[2022-Sep-26 14:43:26 (UTC+2:00)]: U24EU53 manually disabled WSS Agent
[2022-Sep-26 14:43:26 (UTC+2:00)]: Tunnel#2(U24EU53) Disconnected: Nat IP: 10.247.4.227
[2022-Sep-26 14:43:34 (UTC+2:00)]: U24EU53 reenabled WSS Agent
[2022-Sep-26 14:43:34 (UTC+2:00)]: CTC Response: ACTIVE(PRECHK) egress: 203.0.113.1 GFRPA-46.235.155.164 GBEBR-46.235.155.164 GNLAM-98.158.252.164 GDEFR-199.247.40.164
[2022-Sep-26 14:43:35 (UTC+2:00)]: Attempting to connect to GFRPA via UDP
[2022-Sep-26 14:43:36 (UTC+2:00)]: CA Tunnel#3(U24EU53): connecting to 46.235.155.164
[2022-Sep-26 14:43:36 (UTC+2:00)]: CA Tunnel#3(U24EU53): status:SUCCESS-authorized
[2022-Sep-26 14:43:36 (UTC+2:00)]: Tunnel#3(U24EU53) connected to concentrator: 46.235.155.164(GFRPA-UDP), Nat IP: 10.236.65.247, RcvBuf: 2097152
[2022-Sep-26 14:43:36 (UTC+2:00)]: Connection to WSS successful
[2022-Sep-26 14:43:37 (UTC+2:00)]: Waiting for user authentication (U24EU53)
[2022-Sep-26 14:44:15 (UTC+2:00)]: U24EU53 manually disabled WSS Agent
[2022-Sep-26 14:44:15 (UTC+2:00)]: Tunnel#3(U24EU53) Disconnected: Nat IP: 10.236.65.247
HAR file shows one GET request to pod.threatpulse.com starting the auth process at 14:43:37 but instead of getting a 307 redirect we get a 204 response with no payload.
Debug WSS Agent logs for this session show that DNS request/response bypassed WSS Agent and hence subsequent request was not sent into agent tunnel - causing auth to break.