Starting from macOS 15 (macOS Sequoia), a new pop-up is triggered: “Local Network Privacy.” We have some questions regarding this new pop-up on MacOS: Running the following simple code: cups_dest_t *dests; int num_dests = cupsGetDests(&dests); triggers the “Local Network Privacy” pop-up. Question: Is this intended behavior? Even if the user presses the “Deny” button, printers can still be iterated, and it is possible to set options for the printer. Is this intended behavior? If so, which actions related to the CUPS library will be denied when the user presses the “Deny” button? Question: Should this pop-up appear for daemons/launchd processes? We found similar questions on some forums, but the answers are unclear. It seems that the pop-up should not appear for launch daemons. We tested the mentioned code with CUPS, and the pop-up was triggered. Is this a bug? If so, will it be resolved before the new macOS version is released? Question: There is somewhere documented all the scenarios in which this pop-up may appear is challenging? Regarding automatically allowing or disallowing the pop-up: We found the following response: “There is no way to automatically allow or disallow the local network privacy prompt. If it shows up in your app, you will need to analyze your code to better understand how the prompt is being triggered. If the prompt is triggered by a library you do not control, you will need to either remove the library or inquire further with the library vendor.” Question: How can we ensure that a launchd daemon will work as expected if the user presses the “Deny” button? Is there any way to detect if the user pressed “Deny”?

When we try to run our code that uses the containerURLForSecurityApplicationGroupIdentifier function, the returned value is null if the program was run with root privileges. (when we run the code like a normal user, it is works as expected) The following code was run: NSFileManager* fileManager = [NSFileManager defaultManager]; if(!fileManager) { return “”; } NSURL* containerURL = [fileManager containerURLForSecurityApplicationGroupIdentifier:[NSString stringWithUTF8String:group_name]]; if(!containerURL) { return “”; } -> we will receive the right containerURL: /Users/{user}/Library/Group Containers/{group_name} If the same code will be run with root/admin privileges the containerURL will be NULL. With an older version of MacOS the output result was the following: normal user: /Users/{user}/Library/Group Containers/{group_name} root user : /private/var/root/Library/Group Containers/{group_name}

We try to install our network extension that uses NETransparentProxyProvider. For transparent proxy we set two important and general rules: NENetworkRule(destinationNetwork: "0.0.0.0", prefix: 0, protocol: .TCP) NENetworkRule(destinationNetwork: "::", prefix: 0, protocol: .TCP) Our network provider supports IPv4 and IPv6 (the both of them are enabled). Our query is why if IPv6 is enabled and network extension is enabled the Chrome browser doesn't works? (If IPv6 is disabled or network extension is disabled the Chrome works as expected, we observed this behaviour only for Chrome browser) PS: The handleNewFlow function is implemented to return false every time, but it is not called at all for the IPv6 rule

How is it possible to create connection from a network extension (com.networkExtension1), such that, when intercepted in another network extension (com.netext2), the other network extension will see the connection as if it is made by the original source application? This is a snippet from console logs: com.networkExtension1 (0): Flow 2954186858 is connecting com.networkExtension1 (2954186858): New flow: NEFlow type = stream, app = org.mozilla.firefox, name = , 192.168.0.228:0 <-> 35.209.241.59:443, filter_id = , interface = en0 com.networkExtension1 [Extension com.networkExtension1]: Calling handleNewFlow with TCP org.mozilla.firefox[{length = 20, bytes = 0xa2a22e10254b79501b5eda722e4bc1f5acfa70cf}] remote: 35.209.241.59:443 interface en0 com.networkExtension1 NESext handleNewFlow called com.networkExtension1 [Extension com.networkExtension1]: provider accepted new flow TCP org.mozilla.firefox[{length = 20, bytes = 0xa2a22e10254b79501b5eda722e4bc1f5acfa70cf}] remote: 35.209.241.59:443 interface en0 com.networkExtension1 [C72 1DFFC5DD-817A-4B66-836F-12D80F038F41 IPv4#1a7fd949:443 tcp, indefinite, context: Default Network Context, proc: E43CF8FA-B973-3B6F-A3E7-B783A62940F0] start com.networkExtension1 [C72 IPv4#1a7fd949:443 initial path ((null))] event: path:start @0.000s com.networkExtension1 [C72 IPv4#1a7fd949:443 waiting path (satisfied (Path is satisfied), interface: en0, ipv4, dns, flow divert agg: 2)] event: path:satisfied @0.000s, uuid: F6A32047-4E9A-4420-A81A-58CCD66D8BA9 com.netext2 (0): Flow 3811671999 is connecting com.networkExtension1 [C72 IPv4#1a7fd949:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, dns, flow divert agg: 2)] event: flow:start_connect @0.001s 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 com.networkExtension1 nw_connection_report_state_with_handler_on_nw_queue [C72] reporting state preparing com.netext2 [Extension com.netext2]: Calling handleNewFlow with TCP org.mozilla.firefox[{length = 20, bytes = 0xa2a22e10254b79501b5eda722e4bc1f5acfa70cf}] remote: 35.209.241.59:443 interface en0 com.netext2 Flow HANDLER: 4804657760 - TCP org.mozilla.firefox[{length = 20, bytes = 0xa2a22e10254b79501b5eda722e4bc1f5acfa70cf}] remote: 35.209.241.59:443 interface en0 In this case we have 2 network extensions: com.networkExtension1 (network extension 1), com.netext2 (network extension 2) This is the scenario: one connection is made by Firefox browser (the browser is not important) the connection is intercepted by com.networkExtension1 the connection is accepted by network extension 1 a connection is made from network extension 1 a new flow is generated (Flow 3811671999) (3811671999): New flow: NEFlow type = stream, app = com.networkExtension1 (here the app is network extension 1) in network extension 2 (com.netext2) in handleNewFlow function tcpFlow description is "org.mozilla.firefox" (not com.network extention1) Why the same flow (3811671999 from example) once is displayed from network extension 1 and once from com.mozilla.firefox? It is possible to set metadata for a new connection as parameter in NWConnection? If yes how we can do this?

We have a problem when another solution uses a transparent proxy or an app proxy provider. (Network Extension OTHER). When this solution is installed (Network Extension OTHER) we will exclusively receive in our network extension (Network Extension AAA) all the connections from the mentioned network extension (no flow received from browsers or other applications; this is a normal behaviour if the mentioned solution received the connections first). In our network extension we redirect all the connections for all monitored apps. If we monitor the mentioned solution we will intercept all connections from the VPN (from Network Extension OTHER), but these connections will be redirected to our local proxy. In our local proxy we will analyze the traffic and one connection will be created from our local proxy to the server, intercepted again by the mentioned third party solution (infinite loop). If the vpn solution uses NETransparentProxyProvider, they can ignore our local proxy process to not monitor again the flow and all good. If the vpn solution uses NEAppProxyProvider, they will intercept all the connections (also from our local proxy) and we will get into an infinite loop. Our questions: Is it possible to identify the original process (not network extension OTHER process)? Can we force our network extensions to receive the connection firstly? Can we do something regarding this situation to avoid an infinite loop when another network extension is installed (in our environment)? Do we have a solution to resolve this problem with 2 network extensions without involving the developers from the mentioned VPN solutions (network network extension OTHER )? (We control only the Network extension AAA and local proxy).

When we try to run our code that uses the IOBluetoothRegisterForDeviceConnectNotifications function we get a "missing symbol" crash on macOS Monterey Beta 3. Was this function deprecated starting from macOS Monterey? On macOS BigSur everything is work as expected. If yes, is there any workaround or other function which can be used? P.S: a simple code was added (main.cpp.txt) main.cpp.txt

We try to install our network extension that uses NETransparentProxyProvider. The pop-up which requires approval for network extension installation is displayed and after the user approval the installation completes successfully. A second pop-up to allow the proxy manager is displayed and after user approval the proxy manager is displayed in the "Network Preferences". However, when we try to connect the proxy manager in "Network Preferences", it is immediately disconnected. We encountered this issue on a few macOS computers. In the system logs we can see the following errors from "nehelper" and "nesessionmanager": error 08:10:20.609730-0600 nehelper connect failed on kernel control socket: [22] Invalid argument error 08:10:20.609842-0600 nesessionmanager received invalid kernel control socket result 22 error 08:10:20.610177-0600 nesessionmanager Failed to get a flow divert control socket The network extension is signed correctly and has the required entitlements, but from the above logs it looks like it can't be started. Our query is why our proxy manager can't be started? The "Console" logs are here: " default 08:10:20.605458-0600 nesessionmanager Signature is valid and has the correct designated requirement default 08:10:20.608908-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Plugin NEFlowDivertPlugin( xxxxxxxxxxxxxxxxxxxxxxxxxxxx[inactive]) initialized with Mach-O UUIDs ( "7CFFB72F-7430-3C24-B6BD-705714151EE4" ) default 08:10:20.609086-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)] in state NESMVPNSessionStateStarting: plugin NEFlowDivertPlugin(xxxxxxxxxxxxxxxxxxxxxxxxxxxx[inactive]) started with PID 1178 error (null) error 08:10:20.609730-0600 nehelper connect failed on kernel control socket: [22] Invalid argument error 08:10:20.609842-0600 nesessionmanager received invalid kernel control socket result 22 error 08:10:20.610177-0600 nesessionmanager Failed to get a flow divert control socket default 08:10:20.610443-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)] in state NESMVPNSessionStateStarting: plugin NEFlowDivertPlugin(xxxxxxxxxxxxxxxxxxxxxxxxxxxx[inactive]) disconnected with reason Plugin initiated default 08:10:20.610516-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Leaving state NESMVPNSessionStateStarting default 08:10:20.610551-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Entering state NESMVPNSessionStateStopping, timeout 20 seconds default 08:10:20.610629-0600 nesessionmanager &lt;NESMServer: 0x7f999b508660&gt;: Request to uninstall session: NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)] default 08:10:20.610661-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: status changed to disconnecting default 08:10:20.610717-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Updated network agent (inactive, compulsory, not-user-activiated, not-kernel-activated) default 08:10:20.611387-0600 UserEventAgent Current file handles for com.apple.networkextension.file-descriptor-maintainer: ( "Network Agent Registration socket (162) 9A2EB44C-9016-4DCD-9BEF-24D73031E9F3 FFCC2D69-BA2F-4DFA-BC4B-C2740832466A 1 (null) agent flags 0", "Policy Session MasterSession socket (177)", "Policy Session LowPrioritySession socket (178)" ) default 08:10:20.611411-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Leaving state NESMVPNSessionStateStopping default 08:10:20.611455-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Entering state NESMVPNSessionStateDisposing, timeout 5 seconds default 08:10:20.611699-0600 UserEventAgent File Handle Maintainer listening for readable events on Network Agent Registration socket (162) 9A2EB44C-9016-4DCD-9BEF-24D73031E9F3 FFCC2D69-BA2F-4DFA-BC4B-C2740832466A 1 (null) agent flags 0 default 08:10:20.611953-0600 xxxxxxxxxxxxxxxxxxxxxxxxxxxx[Extension xxxxxxxxxxxxxxxxxxxxxxxxxxxx]: Session manager connection was invalidated default 08:10:20.611989-0600 xxxxxxxxxxxxxxxxxxxxxxxxxxxx[Extension xxxxxxxxxxxxxxxxxxxxxxxxxxxx]: Deallocating default 08:10:20.612198-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)] in state NESMVPNSessionStateDisposing: plugin NEFlowDivertPlugin(xxxxxxxxxxxxxxxxxxxxxxxxxxxx[inactive]) dispose complete default 08:10:20.612234-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)] in state NESMVPNSessionStateDisposing: all plugins have disposed default 08:10:20.612288-0600 nesessionmanager NESMTransparentProxySession[Primary Tunnel: Proxy:9A2EB44C-9016-4DCD-9BEF-24D73031E9F3:(null)]: Leaving state NESMVPNSessionStateDisposing default 08:10:20.612406-0600 UserEventAgent Current file handles for com.apple.networkextension.file-descriptor-maintainer: ( "Network Agent Registration socket (179) 9A2EB44C-9016-4DCD-9BEF-24D73031E9F3 FFCC2D69-BA2F-4DFA-BC4B-C2740832466A 1 (null) agent flags 0", "Policy Session MasterSession socket (180)", "Policy Session LowPrioritySession socket (181)" ) "