Cannot apply macOS software updates when WSS Agent active on macOS device

Products

• Cloud Secure Web Gateway
• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet sites via Cloud SWG using the WSS Agents running on macOS/Windows without issues.

Using WorkspaceOne as the MDM used to push macOS changes, the macOS admin team found that pushing an automatic MAC update with MDM WorkspaceOne always failed when WSS Agent was active.

A manual upgrade on the macOC host would also fail, without any MDM push.

WSS Agent setup to bypass all traffic destined to apple.com from Cloud SWG.

The download appeared to start but would fail after a minute or so - launching the softwareupdate command pushed out by MDM manually also showed the problem where message "install failed with error: Installation failed" error returned as shown below, with a number of documented macOS error codes:

Disabling the WSS Agent allowed the update to complete successfully.

Environment

macOS (12.x +).

WSS Agent (All supported versions).

WorkspaceOne MDM.

Cause

macOS update traffic is being sent DIRECT (bypassing Cloud SWG) initially and then into Cloud SWG.

With domain based bypasses, the Agent is dependent on being able to see DNS requests for all the domains we are bypassing ... yet the Agent never saw any DNS A records on the wire for the apple domains used by the softwareupdate process.

 

Resolution

Add an Application bypass for the softwareupdated daemon so that all traffic from this PID is bypassed from Cloud SWG.

e.g. /System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdated 

Additional Information

With the apple.com domain, the WSS Agent should be bypassing traffic destined for swcdn.apple.com (where downloads take place) from going into Cloud SWG, but it is not.

From the Symdiag PCAPs, the traffic destined for swcdn.apple.com is clearly seen to go via the Cloud SWG tunnel (capture-tun PCAP) to the host initially, and then DIRECT (capture-net PCAP).

Although the TCP and SSL connection is always completed when going through the tunnel into Cloud SWG, there appears to be very little traffic exchanged - 18 TCP segments for  every connection through the agent, and 5k with every TCP session, but larger numbers (10MB per TCP connection) when going direct). 

We could also have bypassed 17.0.0.0/8 to get this to work (17.0.0.0/8 block is assigned to Apple); bypassing 17.253.0.0/16, which were visible in the PCAPs when the upgrade started, allowed the update to progress further but never complete.

The PID bypass is the recommended approach.