Hello, I am working on Network Extension and I have faced with the same issue: 10:33:53.854803+0300 com.my_app.transparentproxy (0): data: write error: Message too long 10:33:53.854840+0300 com.my_app.transparentproxy (0): Aborting the director 10:33:53.854862+0300 com.my_app.transparentproxy (1452558381): Got an error when sending 131072 bytes to the kernel: Message too long Looks like the issue appears with buffer length 131072 which is equal to 2^17 in all logs above (my and other threads). In my system net.inet.tcp.recvspace is equal to 131072 # sysctl -n net.inet.tcp.recvspace 131072 I solved this issue by restriction of max buffer length (64k) (system call nw_connection_receive). I found the solution by trial and error. In case of using (net.inet.tcp.recvspace -1), I see the same issue. So, it is unclear max value of the maximum_length. Are there any recommendation? Thank you in advance, Pavel

That sounds promising. Thank you a lot for this information!

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!