macOS users running WSS Agent cannot connect to internet via mobile hotspot

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Corporate users access internet via Cloud SWG service using WSS Agents on both Windows and macOS.

Starting end of February 2024, a number of macOS users reported not being able to connect to Cloud SWG when using iPhone mobile phone hotspot. 

Testing the same iPhone mobile phone hotspot for a Windows WSS Agent worked fine.

Any web site bypassed from Cloud SWG would render successfully.

WSS Agent diagnostic logs confirmed that no tunnel was established into Cloud SWG.

Testing the same use case with other iPhones connected to other Telecom providers seem to prove more successful, where the WSS Agent tunnel would come up fine.

Environment

macOS WSS Agent.

Cloud SWG.

Tethering macOS to mobile device.

Using EE Telecom provider.

Cause

All communication via EE using native IPv6 without any IPv4 gateway.

Resolution

Disable IPv6 for communication into this EE network.

There are options to change the hotspot settings on an Apple discussion forum that we used. This link outlines two possibilities:

• If your MacBook Pro connects to a Wi-Fi network with IPv6 preference, it might prioritize IPv6 connections. You can try to prioritize IPv4:
   
  • Go to System Preferences > Network.
  • Connect to Hotspot and click Details (Refer to the pic below).
  • Under the TCP/IP tab, configure IPv6 settings to "Link-local only" or "Manually"
  • Apply the changes and reconnect to the iPhone's hotspot. 
    
    
• Disable IPv6 on iPhone's Personal Hotspot: Unfortunately, iOS does not have a built-in setting to disable IPv6 on the Personal Hotspot. However, you can try to disable IPv6 globally on your iPhone:
  
  
  • Go to Settings > Cellular > Cellular Data Options > Voice & Data.
  • Select LTE (if available) or choose a lower option.

 In our case, we went with the first option above and all worked fine.

Additional Information

When replicating the issue and grabbing the Symdiag, we confirmed that the Agent never got a CTC response pointing to the nearest POPs, explaining why the tunnel never came up.

Diagnostic log snippet below was started in debug mode at 15:07:48 and stopped at 15:08:03. At no point in Symdiag PCAPs during this time do we generate an IPv4 requests and hence we never connect to WSS which requires an IPv4 address,

[04-05-2024 15:07:47 (UTC+1:00)]: Tracing has been enabled
[04-05-2024 15:07:48 (UTC+1:00)]: Started In-Tunnel PCAP to /tmp/wssa-diag.86604/archive/WssaInTunnelTrace.pcap
[04-05-2024 15:08:02 (UTC+1:00)]: Routing has changed - traffic to ctc.threatpulse.com now routed through interface with address: 192.0.0.2
[04-05-2024 15:08:02 (UTC+1:00)]: CTC: ignoring system proxy settings
[04-05-2024 15:08:02 (UTC+1:00)]: (Notifier) Reloading network extension for VPN
[04-05-2024 15:08:03 (UTC+1:00)]: Stopped In-Tunnel PCAP to /tmp/wssa-diag.86604/archive/WssaInTunnelTrace.pcap

During the period we cannot connect to CTC, we clearly see that every PCAP entry shows an IPv6 address; including the DNS request for ctc.threatpulse.com which asks for an IPv6 response (AAAA) and no A (IPv4) record.

With other working telco providers, an IPv6/v4 gateway would always result in connections to CTC getting responded, and the tunnel establishing.