Post

Replies

Boosts

Views

Activity

Reply to Sending out to actual dest after the Packet intercepted by NEPacketTunnelProvider
@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?
23h
Reply to Sending out to actual dest after the Packet intercepted by NEPacketTunnelProvider
@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?
3d
Reply to Why is localEndpoint not available for NEAppProxyTCPFlow?
@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.
1w
Reply to Crashes in NEFilterPacketInterpose createChannel
@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
May ’25
Reply to Dealing with blocking nature of method handleNewFlow of NETransparentProxyProvider
The trick is to allow the flow and then block all of its traffic until you’ve decided what to do. @DTS Engineer As per this trick, lets say we returns true to allow the flow, later on different queue/thread we decided to handover the flow to kernel, that's not possible right? in this case, only options left are to close the flow, or send it to actual destination, or send it to proxy. No way it can be handed over to kernel which happens after returning false from this method.
Aug ’24
Reply to Network extension process not getting auto launch after installation
@eskimo an ES sysex always has demand. You mean if i add com.apple.developer.endpoint-security.client to YES in capabilities, then it will auto launch after installation? Any help on how to request this entitlement? Or any configuration which can cause demand for launch without using ES entitlements What are you trying to do with that code? There are few things we want to do such as monitoring interface changes using NWPathMonitor, start Unix domain server(there is another process which will connect to this server) etc
Feb ’24