We have code inside our network extension to create NWConnection with destination to loopback address 127.0.0.1 with a specific port number that another process is listening to. This method has been working fine until we test it on macOS 14.2 Beta (23C5030f) where we observed the following error: (Network) [com.apple.network:connection] nw_connection_copy_connected_local_endpoint_block_invoke [C42] Connection has no local endpoint and accessing the connection.currentPath.localEndpoint would return nil. This eventually leads to connection failure. This error is only observed with connection to loopback address. NWConnection created with destination to real address (Eg. on en0 interface) does not have any issue. This error is not observed with all connections to loopback address. Some NWConnection objects would still contain the localEndpoint. Here is an example of all log messages we get for a specific connection: (Network) [com.apple.network:connection] [C42 D9F43B3D-6832-4581-9B3B-12F6F5C7C408 127.0.0.1:49154 tcp, attribution: developer, context: Default Network Context (private), proc: 0D165C5B-CDFE-3F43-BC52-1DFCD61739E6, prefer no proxy] start (Network) [com.apple.network:connection] [C42 127.0.0.1:49154 initial parent-flow ((null))] event: path:start @0.000s (Network) [com.apple.network:connection] [C42 127.0.0.1:49154 waiting parent-flow (satisfied (Path is satisfied), viable, interface: lo0)] event: path:satisfied @0.000s, uuid: 6655EA53-47F9-4B16-85D6-7B81FA0C360E (Network) [com.apple.network:connection] [C42 127.0.0.1:49154 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: lo0)] event: flow:start_connect @0.000s (Network) [com.apple.network:connection] nw_connection_report_state_with_handler_on_nw_queue [C42] reporting state preparing (Network) [com.apple.network:connection] nw_socket_handle_socket_event [C42:1] Socket received CONNECTED event (Network) [com.apple.network:connection] nw_flow_connected [C42 127.0.0.1:49154 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: lo0)] Output protocol connected (socket) (Network) [com.apple.network:connection] [C42 127.0.0.1:49154 ready socket-flow (satisfied (Path is satisfied), viable, interface: lo0)] event: flow:finish_connect @0.000s (Network) [com.apple.network:connection] nw_connection_report_state_with_handler_on_nw_queue [C42] reporting state ready (Network) [com.apple.network:connection] [C42 D9F43B3D-6832-4581-9B3B-12F6F5C7C408 127.0.0.1:49154 tcp, prefer no proxy, attribution: developer] cancel (Network) [com.apple.network:connection] nw_connection_copy_connected_local_endpoint_block_invoke [C42] Connection has no local endpoint (Network) [com.apple.network:connection] [C42 D9F43B3D-6832-4581-9B3B-12F6F5C7C408 127.0.0.1:49154 tcp, prefer no proxy, attribution: developer] cancelled [C42 6655EA53-47F9-4B16-85D6-7B81FA0C360E <NULL><->127.0.0.1:49154] Connected Path: satisfied (Path is satisfied), interface: lo0 Privacy Stance: Not Eligible Duration: 0.001s, TCP @0.000s took 0.000s bytes in/out: 0/0, packets in/out: 0/0, rtt: 0.001s, retransmitted bytes: 0, out-of-order bytes: 0 ecn packets sent/acked/marked/lost: 0/0/0/0 Questions: Why is loopback address special in this case as issue is only observed with connections to loopback address? What we should do in terms of updating our code inside network extension to get this working in macOS 14.2?

We have implemented a NEFilterDataProvider in our Network Extension. We want to utilize the WebContentFilter payload within the Device Management Configuration profile to allow the functionality of our content filter. In the Device Management Profile documentation, there are three properties that are related and seems to have some conditions around them: FilterBrowsers, FilterPackets and FilterSockets. It stated that "At least one of FilterBrowsers or FilterSockets needs to be true" for FilterBrowsers, "At least one of FilterPackets or FilterSockets needs to be true" for FilterPackets, and At least one of FilterBrowsers or FilterSockets needs to be true" for FilterSockets. Based on the above conditions, if we only set FilterPackets to true and ignore the other two properties, it would not satisfy the condition for FilterSockets as both FilterBrowsers and FilterSockets are false. However, during testing we found out that this still works and our content filter is filtering traffic as expected. Does this mean only ONE of the THREE properties need to be true? Or should we make changes according to the documentation to have it align with all conditions and requirements? Any clarifications of the properties and their requirements are much appreciated!