Thanks Matt! I've added logs to this bug report. P.S - since fixing this issue/ finding a workaround is important to us, will it help to speed things up if I'll request a DTS?

Follow up: I tried to remove all the //handle packets code, so for testing purposes, this is the function: func readPacketsFromTUN(_ packets: [Data], protocols: [NSNumber]) { 	packetFlow.readPackets { inPackets, inProtocols in  		 self.readPacketsFromTUN(inPackets, protocols: inProtocols)   } } And the problem still reproduces. Removing the repeated calls to packetFlow.readPackets, will "fix" the problem and deinit will be called. Isn't it suggesting about some memory leak at the extension?

Reproduced also on macOS 10.15.7, I submitted bug FB8938775

Thanks for the reply! Just in case you missed it, I also submitted a DTS request - 752661142. As for your questions - I'm working with DTLS protocol: For sending traffic - I'm reading data from the packetFlow, adding to it some headers, using openSSL and send it. For the other side I'm doing the opposite - I'm getting it decrypted via openSSL, removing some headers, and only then writing it to the packetFlow. I'm not working with Data directly, I'm getting a char* (C string), hence the conversion I have to make. Also, in case it's relevant - I'm writing to packetFlow one packet at a time (and not array full of packets). And as you said, I'm not seeing any leaks, but I'm not sure if it's ok that the app will have a huge physical footprint

P.S - regarding the autoreleasepool, it's becoming a very big pool, I'm not sure it drains correctly. I've submitted a DTS - 752661142

Using Instruments, I can see a lot of small allocations around packetFlow.writePackets(). Can you please look at this short (and simplified) code and check if something is wrong? I can also submit a DTS for this case if needed. This is the relevant code: ondatarecv_fn() is a callback function from C, with a pointer to one packet. I'm converting the pointer into a Data, and write it to the packetFlow. I've added the autorelease there because without it - the app physical footprint is huge. But I think that after some time the VPN is connected, this autorelease pool causes other problems. Without this autorelease there are many Data() allocations. func on_data_recv_fn(_ buf: UnsafeMutablePointer<CChar>?, length: CInt, user_data: UnsafeMutableRawPointer?) -> CInt {     var succeededWriting = 0         buf?.withMemoryRebound(to: UInt8.self, capacity: Int(length), { bufAddress in             autoreleasepool {                 let data = Data(bytes: bufAddress, count: Int(length))                 succeededWriting =  PacketTunnelProvider.sharedInstance.packetFlow.writePackets([data], withProtocols: [PacketTunnelProvider.protocolTypeIPv4])             }         })     return CInt(succeededWriting) }

I captured the traffic coming to the device. The URL is correct. However, at the appDelegate application(_ app: , url: , options:) function, the URL is with the '#' at the end. Any idea what's causing this?

Thanks for the suggestion, but what do you mean by "start with readPackets" ? It's used for reading IP packets from the TUN interface, but it can't fail / report error in any way AFAIK

I reproduced the error (on macOS 10.15.7) and opened a bug - FB8831327

@meaton - regarding "It is absolutely possible to distribute Developer ID Network Extension apps outside the Mac App Store" - are you sure it's possible to distribute Network Extension apps with Developer ID outside the Mac App Store? Or did you mean to Network System Extension? Edit: I'm talking about Packet tunnel providers, according to https://developer.apple.com/documentation/networkextension/packet_tunnel_provider: Packet tunnel providers are supported in iOS and in macOS for Mac App Store apps only.

Any update on this one?

Update: I just found this issue reported a year ago: https://developer.apple.com/forums/thread/107283?answerId=359856022#359856022

@a2zit That's great! I'm also using C code (also for a common code for iOS and Android), but I'm just passing the packets from the packetFlow. I though that using this trick might not work well at the future, so on my side only Android uses FDs. Because of that I don't know the answer to your question, and I'm guessing I'll have to deal with it soon for parts in my code. This, and a similar issue where I want lib curl to send traffic via the tunnel from the extension.

Hi @a2zit  Can I ask in which APIs did you use? I asked the same question ~2 years ago, and the suggestion was to use createTCPConnectionThroughTunnelToEndpoint:enableTLS:TLSParameters:delegate: createUDPSessionThroughTunnelToEndpoint:fromEndpoint: But I didn't test it yet. Any chance you are already using those functions? P.S: My question from 2 years back: https://developer.apple.com/forums/thread/94430?answerId=288108022#288108022

If you are not working in a managed environment what about NEDNSSettingsManager? I wasn't familiar with that one! It sounds great, but sadly it's only from the recent OS versions, so I'll check if this can help us here. Thanks for the suggestion!