Found the fix for this. The sample testbed project for TransparentProxyProvider has synchronisation issue and is causing 'fatalError()' in 'extension Network.NWEndpoint', which causes crash of network extension. Fix for this synchronisation is to pass 'SupportFlow' as async argument:     if (supportedFlow != nil) {       self.queue.async { **[supportedFlow] in**         if (shouldBlock == true) {           // TODO with proper handling of flow           os_log(.debug, log: self.log, "TransparentProxy Provider want to block this TCP flow, flow: 0x%zx", flow.osLogID)           let error = NSError(domain: "", code: 0, userInfo: [NSLocalizedDescriptionKey : "Connection Refused"])           flow.closeReadWithError(error)           flow.closeWriteWithError(error)                     } else {           self.core.handleNewSupportedFlow(supportedFlow!, proxyServer!, proxyPort!)         }       }       os_log(.debug, log: self.log, "Provider did handle new flow, flow: 0x%zx", flow.osLogID)       return true     }

Hi @meaton, One more clarification: Is my understanding correct for Apple's recommend approach, please correct me if I am wrong at any place: PacketTunnelProvider class in NetworkExtension framework can be used to activate and configure the utun interface. Now to define the network rules: either use "NEPacketTunnelNetworkSettings, ipv4Settings" settings or use "route add " command to route traffic on utun interface manually Now for tunneling IP-Packets, read/write operation can be directly done on the utun interface either by an app/service inside or outside the App Group. TIA

Thanks for your response Meaton. I understand what you are trying to explain. I will discuss the options and limitations internally with my team. One more data if you can share, do you see possibility of removing 'utun' support from Apple, if yes, anytime lines? This data will be a critical input for us for discussion making.

Also as i read more, it seems tun driver is by default built-in in MacOS, so if we already have this driver installed why not use it to intercept layer 3 packets for tunneling. I want to understand what limitations it have?

Thanks for the response @meaton, I wanted to understand it further on how the manual route of creating utun interface and doing read/write can limit any functionalities. I was going through openvpn code and seems they also have used manual method to create utun interface to read/write operation for tunneling L3 packets. For me also it seems an easier way to use the utun method as it is easy to maintain the code avoiding the sandboxing and app groups and managing the inbound and outbound connections..

Feedback generated for this request: https://feedbackassistant.apple.com/feedback/9779236

Thanks Owara for sharing the info. I will pass this information accordinly.

This is serious security concern as a user can disable Proxy client by using this option thus exposing mac machines and company resources to malicious access in internet. I will raise the feedback/enhancement request for the same but will request to take it on priority.

Thanks for the response Quinn.