Hello, We have a Network extension transparent proxy (NETransparentProxyProvider) that receives browser TCP flows as NEAppProxyTCPFlow. For each flow we create an NWConnection to the flow's original destination and set NEParameters.preferNoProxies = true - expecting the outbound connection to bypass the user's HTTP/HTTPS proxy and PAC so it goes to the destination server directly. However, in practice we see connections still being redirected to local proxy after being evaluated against the PAC rules using the destination IP and port. Our questions are: Could we expect preferNoProxies to be respected when a PAC exist on the endpoint and supersede the PAC rule decision? If yes, what would be the best way to file a bug and what information do you need? If not, is there any other way of making sure that the outbound NWConnection created by the transparent proxy is not redirected to a proxy and goes directly to the destination? One other way of avoiding our NWConnection being redirected to the proxy is to use hostname instead of destination IP. Would there be a reliable way of getting hostname for the NEAppProxyTCPFlow so that PAC can correctly filter all NWConnection based on rules? We have explored remoteHostname but it's generally not available for connections from browsers other than Safari.

Hello, We have a Network extension transparent proxy (NETransparentProxyProvider) that receives browser TCP flows as NEAppProxyTCPFlow. For each flow we create an NWConnection to the flow's original destination and set NEParameters.preferNoProxies = true - expecting the outbound connection to bypass the user's HTTP/HTTPS proxy and PAC so it goes to the destination server directly. However, in practice we see connections still being redirected to local proxy after being evaluated against the PAC rules using the destination IP and port. Our questions are: Could we expect preferNoProxies to be respected when a PAC exist on the endpoint and supersede the PAC rule decision? If yes, what would be the best way to file a bug and what information do you need? If not, is there any other way of making sure that the outbound NWConnection created by the transparent proxy is not redirected to a proxy and goes directly to the destination? One other way of avoiding our NWConnection being redirected to the proxy is to use hostname instead of destination IP. Would there be a reliable way of getting hostname for the NEAppProxyTCPFlow so that PAC can correctly filter all NWConnection based on rules? We have explored remoteHostname but it's generally not available for connections from browsers other than Safari.

We are implementing a Network Extension that uses NETransparentProxyProvider. For browser TCP flows we terminate in the extension and re‑originate traffic with NWConnection. Per documentation, we set NWParameters.preferNoProxies = true on that NWConnection so it should not use the system HTTP/HTTPS proxy configuration, including PAC‑selected explicit proxies. Observation: With System Settings → Network → Proxies → Automatic proxy configuration pointing at a PAC file that returns something like PROXY 127.0.0.1:8888 for relevant traffic, we still see our NWConnection traffic show up at the local explicit proxy as a normal CONNECT host:443 tunnel. That suggests PAC / explicit proxy selection is still being applied to sockets we believed were opted out via preferNoProxies. This is affecting interoperability: the browser may evaluate PAC with a hostname (e.g. a site configured as DIRECT), while a separate NWConnection may be evaluated in a context where the logical host is an IPv4 literal, so the same PAC script can return PROXY for what the user thinks is the “same” destination. We had expected preferNoProxies to remove the second leg from PAC/proxy entirely. Expected: NWConnection with preferNoProxies == true should connect without opening an explicit CONNECT session to the PAC‑configured proxy (unless there is documented behavior that NE‑originated traffic is intentionally exempt from this flag). Actual: Traffic from the NWConnection path still reaches the explicit proxy (we can log CONNECT … on a minimal local proxy). Environment: macOS Tahoe 26.5 (25F71), Network Extension / App Proxy provider, PAC served over local http, Safari as client. Questions: Is preferNoProxies guaranteed to bypass PAC‑selected explicit proxies for NWConnection from Network Extension processes, or are there known exceptions (e.g. certain interfaces, MDM, networkserviceproxy, etc.)? If this is by design, what is the supported way for an NE to open an outbound TCP connection that must not inherit system PAC/proxy?

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!

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?