Thank you for response! I am going to use onDemandRules to startup Transparent Proxy. NEOnDemandRuleConnect *connectRule = [NEOnDemandRuleConnect new]; connectRule.interfaceTypeMatch = NEOnDemandRuleInterfaceTypeAny; Is it supported way?

Hello, Thank you a lot for the time and responses! However, further research into the certificate installation completely confused me. sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain security find-certificate -c "my cert name" -Z | grep "SHA-1 hash:" | awk '{print $3}' security trust-settings-export -d ExportedTrustSettings.plist Modify the 'ExportedTrustSettings.plist' file. Find and remove the section with the key generated in step 2. sudo security trust-settings-import -d ExportedTrustSettings.plist Check if the trust setting is reset. sudo security delete-certificate -c "my cert name" /Library/Keychains/System.keychain sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain Result: the certificate is trusted. I cannot understand whether this is a bug, a feature, or an incorrect use of the 'security' tool. Thank you in advance!

Hello, Thank you for the help. As I understand it, trust settings are stored separately from the certificate. Does this mean that I can pre-configure the necessary settings during the software installation? For example, by having a post-install script call "security trust-settings-import". The second question is about "security trust-settings-import" usage. From what I see, security trust-settings-import operates on an XML file that contains the entire list of trust settings (previously generated by trust-settings-export). Is there a supported way via the command line to import trust settings for only one specific certificate, rather than applying or merging the entire global list? For example, can the XML file be stripped down to only include the target certificate, or is there another CLI approach to apply custom trust settings to a single certificate during installation? Thank you in advance.

thank you for the help!

Hello, Thank you for response. Is there any way to reset the "Always Trust" policy? The following sequence of commands leads to installing a root CA with the "Always Trust" policy: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain //MyCertificate.cer change policy to "Always Trust" sudo security delete-certificate -c "MyCertificate.cer" //MyCertificate.cer sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain //MyCertificate.cer Result: the newly installed certificate is trusted after step 4. Thank you for the help!

thank you for the help!

thank you!

Thank you! Could you please confirm if the installation of a Network Extension strictly required a GUI application and there is no other options without an MDM? (Note: I understand that without an MDM profile, the user will still be prompted to manually approve the system extension in System Preferences/Settings) Thank you for your help!

Thank you for the help! Our cross-platform DLP solution is deployed via a standard .pkg installer and must support macOS 11 and later. The installer sets up a LaunchAgent which is responsibe for system monitoring and launching container app (which bundles NE) when necessary. Once activated, the Network Extension communicates with independently deployed LaunchDaemon via XPC (https://developer.apple.com/forums/thread/820631). To avoid confusing users with unnecessary UI, this container app must run in the background without a Dock icon. Is it officially supported to configure the Network Extension's containing .app as a background-only application by setting LSUIElement = YES in its Info.plist? Is it supported for our independently deployed LaunchAgent to programmatically launch this background-only .app? (Note: I understand that without an MDM profile, the user will still be prompted to manually approve the system extension in System Preferences/Settings) Thanks!

Thank you for the advice! I'm working on a project where this daemon acts as an XPC service, and its main job is to analyze network data provided by a Network Extension. Unfortunately, writing meaningful unit tests for the actual data flow is quite problematic. I believe the best way to debug is the attach-to-process approach (using waitFor / WaitForDebugger). Thanks again for your help!

Thank you for the help!

thank you for the help!

Thank you for the detailed explanation! Regarding the order of transparent proxies: if the application is installed directly by the end-user (meaning it is unmanaged and not deployed via a device manager / MDM), is there any programmatic way to influence which proxy receives the flow first? If not, is the order strictly undefined (e.g., based on the order of installation or activation), and should we just architect our app assuming it could end up anywhere in the proxy chain. Thank you for the help!

Thanks a lot for the help! Since both the Launch Daemon and the Network Extension start at boot-time before user login, is there a guaranteed initialization order between them? Specifically, is one guaranteed to be fully bootstrapped before the other, or should I treat their startup as a race condition? Thank you again.

Thanks for the detailed explanation and tips! Could you please help with two architectural follow-up questions regarding the lifecycle and data flow: Boot-time execution and User Sessions: In Apple's examples, the Network Extension is initially installed and activated via a Container App running within a user session. However, the extension itself runs as root. Assuming the user has approved the extension and the configuration is saved, will macOS automatically bootstrap this Network Extension at boot-time (before any user logs in)? We need to ensure that our global launchd daemon and the Network Extension can establish this App Group-based XPC connection and start filtering traffic regardless of active user sessions. Confirming the IPC Roles: Given your suggestion to set the MachServices property in the launchd daemon, am I correct in assuming the recommended architecture is strictly: Launch Daemon = XPC Listener / Server (handling complex analysis) Network Extension = XPC Client (acting purely as a data provider pushing intercepted flows to the daemon) Is there ever a valid use case where these roles should be reversed in a system-wide filtering context, or is the Daemon-as-Listener the absolute standard here? Thanks a lot for your help!