@DTS Engineer So what do you do in those methods? We don't do anything here. override func wake() { EPLog(debug, "provider wake", module: Consts.Module.ProxyProvider) } override func sleep(completionHandler: @escaping () -> Void) { EPLog(debug, "provider sleep", module: Consts.Module.ProxyProvider) completionHandler() } We apply rule during: override func startProxy Why does it stops intercepting traffics?

@DTS Engineer If there is already 4 Filter extension enabled, 5th one fails and below is the log stream output. Exceeded Content Filter limit, TESTFilter superceded 2026-03-08 11:44:17.270577+0530 0x198d3    Default     0x0                  466    0    nehelper: (NetworkExtension) [com.apple.networkextension:] +[NEConfigurationManager configuration:overlapsWithOtherConfiguration:sameTypeCount:perAppCount:]: Exceeded Content Filter limit, TESTFilter superceded I have tested this on macOS 26.3.1 Is this documented somewhere?

And please post your bug number, just for the record. FB21966111

@DTS Engineer Enhancement request for record: FB21501041

Thanks much @DTS Engineer The issue is intermittent and typically occurs when running the E-commerce iOS app, which generates a high volume of traffic. The strange part is that even after closing the simulator, the internet issue does not get resolved. Do you think we can add exception rules in NE—such as based on IP, domain, process, or port—to help mitigate this? If so, could you please suggest what specific exceptions we should consider adding?

@DTS Engineer I took following approaches to handle ICMP and UDP bypass: Create a raw socket at helper process side as this is not allowed from extension sandbox environment Upon receiving the pkt from extension over UDS at helper side, change source address of packets to en0 address and recommpute checksum.(source address will have utun address of Pkt Tunnel extn) Send packet on raw socket it will be send to destinations. Inbound traffics comes to kernel ICMP gets deliver to applications. ICMP don’t require explicit binding by the app (system handles it), so raw injection + kernel delivery works naturally Inbound UDP and TCP will not get deliver because kernel doesn’t know which socket to deliver it to recvfrom for rawsocket doesn't works Handling Inbound UDP and TCP sniff en0 using libpcap Maintain some map / state table to pick only intrested packets change the destination back to packet tunnel utun interface address and re compute checksum tell packet tunnel to write it back The final step in our inbound packet processing is failing intermittently. The kernel is silently dropping the packet sometime during the packetFlow.writePacketObjects call, and it never reaches the application. How can we debug why the kernel is dropping it?

@DTS Engineer Thanks for the detailed responses. One technique that typically works is to run your own TCP/IP stack and use that to turn the packets back into flows. You can then use standard networking APIs to proxy those flows. However, this approach has its own problems, which is why DTS doesn’t support it. Following questions around this: If I run my own TCP/IP stack in helper process and use it to send traffic directly to the outside network, will those packets still get intercepted by NEPacketTunnelProvider, given that the provider is currently configured to intercept everything? Running it inside extension process will work due to NECP policy considering Strict sandboxing of extension? Since you mentioned that this approach comes with its own problems, could you please outline some of them?

What do you mean by “device bypass”? By on-device bypass I mean: when my NEPacketTunnelProvider intercepts packets, instead of tunneling certain webstites to a remote VPN server, I want to allow those traffics to go directly out through the device’s native network interface without going through the tunnel.

@DTS Engineer We have a separate module responsible for making decisions—whether to block, send directly, or route through a proxy. This module runs in a different process, and the extension communicates with it via IPC. When the extension receives a flow: The extension accepts the flow and queries the decision module for a verdict (block, direct, or proxy). It sends all metadata except the source port(This is not available). The decision module responds with the verdict and, in the case of a proxy decision, the listener details (loopback IP and port). It also stores the metadata for later use when forwarding the flow to the proxy. If the verdict is "send direct," the extension copies the flow to its actual destination. If the verdict is "send to proxy," the extension copies the flow to the decision module’s listener. Just before sending the flow to the proxy listener, the extension also provides the source port so that the decision module can update the corresponding metadata using the flow ID. When the proxy listener receives the copied flow, it looks up the metadata using the source port, which serves as the only unique identifier at that point. If we could obtain the source port right away and only talk to the decision module once, the whole process would be much simpler.

@DTS Engineer I requested the customer to share a link or any source, but haven’t received a response yet.

@DTS Engineer In my case, user's reported such crashes on m2 pro with very high internet speed. They use ethernet. As per user, mostly it happens when they are on video call with many other user's. In very few time they've seen crashes during sleep. Let me check with these user's if they can collect sysdignose during issues.

@DTS Engineer We're encountering these crashes as well, including on macOS 15. Could this be related to exceptionally high internet speeds? Thread 12 Crashed:: Dispatch queue: com.apple.network.connections 0 libsystem_kernel.dylib 0x19cf9fbd8 os_channel_get_next_slot + 664 1 NetworkExtension 0x1afc07818 __40-[NEFilterPacketInterpose createChannel]_block_invoke + 416 2 libdispatch.dylib 0x19ce2b85c _dispatch_client_callout + 16 3 libdispatch.dylib 0x19ce165e0 _dispatch_continuation_pop + 596 4 libdispatch.dylib 0x19ce29620 _dispatch_source_latch_and_call + 396 5 libdispatch.dylib 0x19ce282f8 _dispatch_source_invoke + 844 6 libdispatch.dylib 0x19ce1c170 _dispatch_workloop_invoke + 1612 7 libdispatch.dylib 0x19ce25264 _dispatch_root_queue_drain_deferred_wlh + 292 8 libdispatch.dylib 0x19ce24ae8 _dispatch_workloop_worker_thread + 540 9 libsystem_pthread.dylib 0x19cfc5e64 _pthread_wqthread + 292 10 libsystem_pthread.dylib 0x19cfc4b74 start_wqthread + 8

@DTS Engineer I am also facing similar issues. Replacing SCNetworkReachability with NWPathMonitor. I couldn't found exact equivalent of SCNetworkReachabilityCreateWithName in NWPathMonitor. Instead it can used to monitor changes in specific interface or all interface. Is there a way to just monitor specific domain with NWPathMonitor?

@DTS Engineer for the system as a whole example: testyoutube.com ping, curl, or any browser etc visits testyoutube.com, i want to resolve it by Transparent Proxy.

Thanks much @DTS Engineer. During KeepAlive true, if process crashes after launch, what best can be done to minimise crash loop or at-least minimising system instability or excessive resource caused by crash loop?