On the computers where we encountered this error, there was an antivirus which also uses a network extension. That antivirus was uninstalled, and the computer was restarted, however the error still persisted. Our application runs without issues on the other macOS computers. Is there a method to understand what causes this problem? One more question: From the "Network" system preferences, the user can press "-" button to delete the proxy manager. If we re-create the proxy manager from our software, a pop-up to allow the VPN proxy will be shown again to the user. Is is possible to avoid this pop-up? I attached the logs: Attached logs

The sample code was tested with the latest update (Beta 4) but without any result, the problem persists.

Hi Matt, Thank you for your fast answer. Just to be sure 100%, is there any attribute how to load one network extension first, or altitude or anything similar? Thank you very much.

Hi Matt, Thanks for your quick answer. If the flow is accepted by network extension 1 a new connection will be made and in network extension 2 we should receive connections from network extension 1. No connections are received in network extension 2 from network extension 1. How it is possible to not see connections from network extension 1 in network extension 2?

Hi Matt, The mentioned log is not from handleNewFlow(_ flow: NEAppProxyFlow) function. This is displayed in console log, but it is not my log (I suppose that was generate automatic by macOS). com.netext2 (3811671999): New flow: NEFlow type = stream, app = com.networkExtension1, name = , 192.168.0.228:0 <-> 35.209.241.59:443, filter_id = , interface = en0 (not my log) In network extension 2 in handleNewFlow function we no receive connections from network extension 1. I expect in the network extension 2's handleNewFlow to receive connections from network extension 1, yet this log: "Calling handleNewFlow with TCP org.mozilla.firefox[{length = 20, bytes...", appears to indicate that the flow is received directly from the Firefox browser. Every time when in handleFlow function is logged the flow.metadata.sourceAppSigningIdentifier, the org.mozilla.firefox (Firefox browser) is displayed. (network extension 1 is an internet security solution)

Hi Matt, Yes this is the desired behaviour to receive in network extension 2 the source application. I tested with 2 anti-viruses and in network extension 2 we have the following results: -> in both of the scenarios the network extension 1 accepts the flow -> when network extension 1 is from an antivirus solution, network extension 2 sees the source as "Firefox". But when network extension 1 is from another, different, antivirus solution, network extension 2 sees the source as "network extension 1". Is there an explanation for the different results which were obtained?

Thanks for your quick reply. I tried exactly with the rules received from you and everything is works as expected. I also have 2 questions regarding this case: Why if I set the following rules the Chrome browser is stil blocked? NENetworkRule( remoteNetwork: nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: .outbound) NENetworkRule( remoteNetwork: NWHostEndpoint(hostname: "172.217.0.0", port: "443"), **remotePrefix: 0, // with 0 NOT WORKS, but with 16 WORKS as expected** localNetwork: nil, localPrefix: 0, protocol: .UDP, direction: .outbound) The remote host for UDP connections are not set (are nil). The remote host should be set? (I attached after question a sample from Console app) I want to monitor/block some IPs on QUIC protocol and I suppose (I test this scenario with Wireshark) the QUIC is intercepted with UDP not with TCP. Is it possible to monitor only some address on UDP protocol? (the rule from example) I tested with 2 set of rules for UDP one with remotePrefix 0 and it is not works, and one with 16 which works as expected. Is there any explanation for this scenario? // NSLog("New UDP flow: (flow.osLogID) - (udpFlow.description) - (udpFlow.metaData.debugDescription) - (udpFlow.remoteHostname)") New UDP flow: 5814370464 - UDP com.google.Chrome.helper[{length = 20, bytes = 0x8336889fb3c42875c64cd9bc36f64da3ca34d1dc}] local port 6339 interface en0 - com.google.Chrome.helper[{length = 20, bytes = 0x8336889fb3c42875c64cd9bc36f64da3ca34d1dc}] - nil New UDP flow: 5802858192 - UDP com.google.Chrome.helper[{length = 20, bytes = 0x8336889fb3c42875c64cd9bc36f64da3ca34d1dc}] local port 0 interface en0 - com.google.Chrome.helper[{length = 20, bytes = 0x8336889fb3c42875c64cd9bc36f64da3ca34d1dc}] - nil

Sorry for misunderstanding, I put the sandbox app because we had a daemon which communicate with a “sandbox app”. For debugging we run the daemon with root credentials: sudo ./daemon We observed the mentioned code above is work as expected if the application was run in the following way: ./application.exe -> the output IS correct sudo ./application.exe -> the output is NOT correct (containerURL is NULL) (this worked as expected on older macos)

Yes, daemon and application.exe are the same thing and sorry again for confusion. If you will run this code/application with/without sudo you will option different things/results. CODE (application.exe): NSFileManager* fileManager = [NSFileManager defaultManager]; if(!fileManager) { return “”; } NSURL* containerURL = [fileManager containerURLForSecurityApplicationGroupIdentifier:[NSString stringWithUTF8String:group_name]]; if(!containerURL) { return “”; } Result/Output: ./application.exe -> the output IS correct sudo ./application.exe -> the output is NOT correct (containerURL is NULL) (this worked as expected on older macos)

The answer is simple, we use a daemon which communicates with an user mode application. The mentioned user mode application was sandboxed which means the file sharing between daemon and other applications was restricted. The only method to communicate/shared files between the mentioned apps (daemon and notifier app) can be made using group specific folder. When the daemon is launched using launchd command the returned value for group app is good (a path is returned) but when we debug our solution (our daemon) we don’t use launchd command, we use sudo command. How we can detect the same group app/the same folder to share files between the daemon and user mode app (notifier app)?

We observed the same behaviour. Before macOS 14.2 we were able to get the local endpoint on the ready state of a NWConnection: let localEndpoint = connection.currentPath?.localEndpoint?.neEndpoint where connection is a NWConnection with the destination set to localhost, and the above code is called from the connection state update handler for connection when the connection state is updated to ready After upgrading to macOS 14.2 Beta, the local endpoint retrieved by the above code is NIL. Other important aspect related to connection.debugDescription when works as expected the following is displayed: connection info [C598 connected 127.0.0.1:27443 tcp, attribution: developer, path satisfied (Path is satisfied), viable, interface: lo0] when not works as expected, the viable attribution is NOT displayed: connection info [C603 connected 127.0.0.1:27443 tcp, attribution: developer, path satisfied (Path is satisfied), interface: lo0] Can we somehow obtain/detect the localEndpoint for a network connection?

All the questions are about macOS launch daemon.

The daemon is running as root (by default), started from: /Library/LaunchDaemons/

The bug was reproduced on macOS 15.0 (24A335). "Simply enumerating the printers from a launchd daemon causes the Local Network privacy pop-up to be displayed." A bug ticket was opened as mentioned: FB15144682.

I updated macOS to 15.1 Beta (24B5046f), and the bug seems to be resolved. Simply enumerating the printers using the CUPS library no longer triggers the 'Network Local Privacy' pop-up."