Hi, We are observing few NEPacketTunnelNetworkSettings excludedRoutes ip's in PacketTunnel even-though it is added in exclude routes. As you can see in network setting where we have added destinationAddress = 239.255.255.0 destinationSubnetMask = 255.255.255.0 in exclude route, still traffic of IP 239.255.255.250 coming to packet tunnel. We also observing other IP's traffic that is not added in include route such as: 20.192.170.9 //Network Settings for Packet Tunnel IPv4Settings = { configMethod = PPP addresses = ( 10.10.10.10, ) subnetMasks = ( 255.255.255.255, ) includedRoutes = ( { destinationAddress = 10.10.10.10 destinationSubnetMask = 255.255.255.255 gatewayAddress = 10.10.10.10 }, ) excludedRoutes = ( { destinationAddress = 192.168.0.0 destinationSubnetMask = 255.255.0.0 }, { destinationAddress = 10.0.0.0 destinationSubnetMask = 255.0.0.0 }, { destinationAddress = 127.0.0.1 destinationSubnetMask = 255.255.255.255 }, { destinationAddress = 172.16.0.0 destinationSubnetMask = 255.240.0.0 }, { destinationAddress = 239.255.255.0 destinationSubnetMask = 255.255.255.0 }, ) am i doing something wrong in setting NEPacketTunnelNetworkSettings?

Description: We are investigating an issue where running a specific e-commerce iOS app inside the Xcode Simulator intermittently disrupts the Mac’s network connectivity. When the app is launched in the Simulator, our NETransparentProxyProvider and NEFilterDataProvider extensions occasionally stop receiving traffic correctly, and shortly afterward the entire macOS DNS resolution fails. Once this happens, all apps on the Mac lose internet access until mac is restarted. Disabling extensions also fixing the issue. This issue only appears when the app runs in the Xcode Simulator. I would like to confirm: Is it possible for traffic patterns or network behavior inside the Simulator to interfere with system-level Network Extension providers on macOS? Are there known limitations or conflicts between the Simulator’s virtual networking interfaces and Network Extensions? Any recommended debugging steps or best practices to isolate this behavior? Any guidance, known issues, or suggestions would be appreciated.

I’m using an NETransparentProxyProvider where I add UDP-53 rules to intercept DNS queries from a private application. These queries are resolved locally on the endpoint by returning a custom DNS response. Example Rules look like this: NENetworkRule(destinationHost: NWHostEndpoint(hostname: "mypaapp.com", port: 53),protocol:.UDP) This works as expected through browser and ping. handleNewUDPFlow/handleNewFlow with NEAppProxyUDPFlow gets called where custom dns response get written. Using nslookup mypaapp.com doesn't works. Why does this behaves differently for nslookup?

Hello, I have created raw socket as below rawSockfd = socket(AF_INET,SOCK_RAW,IPPROTO_IP) Added flag 5 sec SO_RCVTIMEO, IP_HDRINCL to 1 via setsockopt. Sending IP Packet as below: struct sockaddr_in connection = getSockAddr(dstIPAddress);  long bytes = sendto(rawSockfd, (uint8_t *)packet, size, 0, (struct sockaddr *)&connection, sizeof(struct sockaddr)); I am trying to receive as below: long rsize = recvfrom(rawSock, buffer, size, 0, (struct sockaddr *)&connection, (socklen_t *)&addrlen); This works fine for ICMP, UDP. recvfrom able to read packet back. We are facing issue during TCP. recvfrom returns error: Resource temporarily unavailable after 5 sec timeout. If we remove timeout flag SO_RCVTIMEO then it gets stuck forever. TCPdump shows following logs on destination. Instead of SYN ACK it's getting Reset: 09:21:03.972632 IP 10.215.179.1.54745 > 10.207.134.154.8181: Flags [SEW], seq 358899317, win 65535, options [mss 1380,nop,wscale 6,nop,nop,TS val 426499980 ecr 0,sackOK,eol], length 0 09:21:03.972755 IP 10.207.134.154.8181 > 10.215.179.1.54745: Flags [R.], seq 0, ack 358899318, win 0, length 0 is this something macOS not sending TCP response back to rawsocket or something is wrong in my code?

I am trying to get ports used by processes. It can be done via lsof on macOS, i am trying to do it via libproc. #include <iostream> #include <libproc.h> int main(int argc, const char * argv[]) { pid_t pids[3072]; int count = proc_listpids(PROC_ALL_PIDS, 0, pids, sizeof(pids)); for (int i = 0; i < count; i++) { char buffer[1024]; for (int j = 1; j < 50000; j++) { //port range int ret = proc_pidfileportinfo(pids[i], j, PROC_PIDFILEPORTVNODEPATHINFO, buffer, sizeof(buffer)); if(ret != 0) { printf("proc_pidfileportinfo returned %d bytes of data\n", ret); printf("%s\n", name); } } } return 0; } proc_pidfileportinfo function is not working for any port, i tried iterating till 50K. What i am doing wrong with proc_pidfileportinfo? how to properly use proc_pidfileportinfo?

I am trying to pause NEFilterFlow and then resuming NEFilterFlow from function **handleInboundData** let goingToApply = someFunctionWithClosure { applied in if applied { let verdict: NEFilterNewFlowVerdict = .allow() self.resumeFlow(flow, with: verdict) } } if goingToApply == true { return .pause() } The line self.resumeFlow(flow, with: verdict) crashing with following exception: terminating with uncaught exception of type NSException *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NEFilterNewFlowVerdict passBytes]: unrecognized selector sent to instance 0x10b8662a0' Crash dump showing below logs: Thread 3 Crashed:: Dispatch queue: NEFilterExtensionProviderContext queue 0 libsystem_kernel.dylib 0x1b7aa6d78 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1b7adbee0 pthread_kill + 288 2 libsystem_c.dylib 0x1b7a16340 abort + 168 3 libc++abi.dylib 0x1b7a96b18 abort_message + 132 4 libc++abi.dylib 0x1b7a86a54 demangling_terminate_handler() + 336 5 libobjc.A.dylib 0x1b797c320 _objc_terminate() + 144 6 libc++abi.dylib 0x1b7a95eb4 std::__terminate(void (*)()) + 20 7 libc++abi.dylib 0x1b7a95e50 std::terminate() + 64 8 libdispatch.dylib 0x1b79181c8 _dispatch_client_callout + 40 9 libdispatch.dylib 0x1b791f8a8 _dispatch_lane_serial_drain + 668 10 libdispatch.dylib 0x1b7920404 _dispatch_lane_invoke + 392 11 libdispatch.dylib 0x1b792ac98 _dispatch_workloop_worker_thread + 648 12 libsystem_pthread.dylib 0x1b7ad8360 _pthread_wqthread + 288 13 libsystem_pthread.dylib 0x1b7ad7080 start_wqthread + 8 Why this exception is occurring for .allow() verdict only. For .drop() it is not crashing. No where i'm calling passBytes method on NEFilterNewFlowVerdict

Hi, We have NEPacketTunnelProvider which creates a virtual interface. I am trying to Read and write virtual interface in separate process(c++ command line project). Read works fine, but write is not working. Reading packet in separate process as below: int bpf = 0; for (int i = 0; i < 99; ++i) { snprintf(buf, 11, "/dev/bpf%i", i); bpf = open(buf, O_RDWR); if (bpf != -1) break; } struct ifreq interface; strcpy(interface.ifr_name, interfaceName.c_str()); if(ioctl(bpf, BIOCSETIF, &interface) > 0) { return errno; } unsigned int one = 1; if (ioctl(bpf, BIOCIMMEDIATE, &one) == -1) { return errno; } int bufLength = 1; if (ioctl(bpf, BIOCGBLEN, &bufLength) == -1) { return errno; } if (ioctl(bpf, BIOCPROMISC, NULL) == -1) { return errno; } //Reading bpf as below readBytes = (int)read(bpf, bpfBuffer, bufLength); **Whenever traffic routed to Packet Tunnel provider interface as per network rule, Read works fine in this process(separate c++ process). We are able to read valid packet. ** //Writing as below ssize_t writtenBytes = write(bpf, packet, size); if (writtenBytes < 1) { return false; } else { return true; } Above write API is not giving any error, returning byte written correctly. But after write, packet is not reaching to application which generated traffic. For example, for ping, it is showing 1 packets transmitted, 0 packets received, 100.0% packet loss I also tried sending it over raw socket. Since separate process is command line and not sandboxed, raw socket getting openned. `ssize_t bytes = sendto (fRawSocket, packet, size, 0, (sockaddr*) dest, sizeof(*dest)); //dest is packet tunnel virtual interface ip addres` This also not returning any error but this packet is also not reaching to application which generated traffic. There is packetFlow.writePacketObjects which works fine in swift. but due to some architecture constraint, i am reading and writing packet in separate process. is this something macOS doesn't allow or i am doing something wrong?

Hi, I have a dynamic library libmowglicore.dylib, which works fine in non sandboxed enviroment(command line cpp project). libmowglicore.dylib is signed, it shows valid on disk. When i add it to network extension project, network extension getting crash on launch. 0 dyld 0x102c8e81c dyld3::MachOFile::compatibleSlice(Diagnostics&, void const*, unsigned long, char const*, dyld3::Platform, bool, dyld3::GradedArchs const&) + 76 1 dyld 0x102c72b9c invocation function for block in dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int) + 96 2 dyld 0x102c72b9c invocation function for block in dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int) + 96 3 dyld 0x102c77fcc dyld4::SyscallDelegate::withReadOnlyMappedFile(Diagnostics&, char const*, bool, void (void const*, unsigned long, bool, dyld4::FileID const&, char const*) block_pointer) const + 132 4 dyld 0x102c72b08 dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int) + 204 Crash Dumps How to debug it?

Hi, This is how we create ipv4Settings, then we add includedRoutes, excludedRoutes. let ipv4Settings = NEIPv4Settings(addresses: addresses, subnetMasks: subnetMask) In my case, Packet Tunnel Provider reads the packet like this - packetFlow.readPacketObjects, sends packets to C++ module which takes care of sending it to wireguard tunnel, returns packet back to Packet Tunnel Provider for writing. C++ Module does everything related to wireguard tunnel. As per my understanding, any unique private ipv4, ipv6 address should be fine for creating NEIPv4Settings, NEIPv6Settings. is that correct? or is there anything else i need to consider for setting Utun addresses as of now i have harcoded it to 10.10.10.10/32 and 2001:db8::/128, will it cause any problem?

Hi, AFAIK Safari or any macOS apps which uses WKWebview, uses com.apple.WebKit.Networking.xpc to do actual networking. I am working on a packet tunnel, where I am able to get process id associated with packet read. Based on process id, i am using libproc to get process name. I am facing below problem: For Safari or any other apps which uses WKWebview having same process name: com.apple.WebKit.Networking Any ways to distinguish wether it is from safari or other xyz wkwebview apps? Related Problem: https://developer.apple.com/forums/thread/693528 In this thread, app proxy can help but in packet tunnel no such options exposed.

I have a system extension which contains 3 capabilities: App Proxy, Content Filter, Packet Tunnel. System extension process doesn't auto stops on disabling all of its Capabilities: App Proxy, Content Filter, Packet Tunnel How to make system extension process auto stop if all of its capabilities disabled? Disable can happens via system extension hosting app or system preference network settings I have following in mind: Whenever we disables any capabilities via system extension hosting app, it can check if all others are disabled then Use KILL bash command to terminate system extension process System extension hosting app can send message via XPC to extension to terminate it self via NSApp.terminate On disabling from system preference, ssystem extensions can check if all other disables in delegate method and terminate itself I wanted to know what is better way to handle system extension process stop

I have a Network extension contains App Proxy and Content Filter. After installation, extension process is not getting auto launch. We want to execute some code in main.swift. extension process is getting launch on enabling either App Proxy or Content Filter. how to launch network extension process after installation? Installations Sample code: let activationRequest = OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier: id, queue: .main) OSSystemExtensionManager.shared.submitRequest(activationRequest)

my macOS process is crashing when i keep my mac sleep for about 1 hour. Under Crash Reports, Console app shows two type of file. .diag type .ips type ips file doesn't shows exact line of crash as you can see below sample. Thread 67 Crashed: 0 libsystem_kernel.dylib 0x19a4aea60 __pthread_kill + 8 1 libsystem_pthread.dylib 0x19a4e6c20 pthread_kill + 288 2 libsystem_c.dylib 0x19a3f3a30 abort + 180 3 libsystem_malloc.dylib 0x19a303dc4 malloc_vreport + 896 4 libsystem_malloc.dylib 0x19a307430 malloc_report + 64 5 libsystem_malloc.dylib 0x19a321494 find_zone_and_free + 528 6 Firewall.so 0x103c8a744 TunnelSendQueue::ResumeSend() + 460 resource.diag file sgowing warning about exceeding limit of 150 wakeups per second over 300 seconds. attached here. reasource_consumptions_W36RNW09G.wakeups_resource_diag.txt is this something macOS stopping app because of some resource consumptions?

NETransparentProxyProvider have below method: override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool This method is blocking. Until we returns value from this method, next flow will be blocked, macOS doesn’t calls it on new thread. for example: if we take 10 second to check what to do with this flow, whether to handle it(true) or return to kernel(false), another flow will be block for 10 sec. how to not block future flow while it is taking longer to process current flow?

NETransparentProxyProvider having these two methods: override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool override func handleNewUDPFlow( _ flow: NEAppProxyUDPFlow, initialRemoteEndpoint remoteEndpoint: NWEndpoint ) -> Bool During initial days when NETransparentProxyProvider was introduced, We used handleNewFlow to handle NEAppProxyTCPFlow and handleNewUDPFlow to handle NEAppProxyUDPFlow . Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow? will this works always or there are some scenario where keeping handleNewUDPFlow will be usefull?