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

@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.

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 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?

@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?

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?