Thank you for the input. I'll be sure to come back to this post/create a new post if I encounter any problems with my implementation.

For a NEDNSProxyProvider there is no selective proxying. Is there a way to do selective proxying? I am actually in the process of formally documenting the flow copying process right now, but a brief overview is: Out of curiosity, when would this be ready and published? In the case of NEAppProxyTCPFlow how would the process look like? Also, does / how does NEDNSSettingsManager have a place in all of this? Thank you for your help.

Thank you for your clarification. I read here that I would be able to use NEAppProxyProvider - https://developer.apple.com/documentation/networkextension/neappproxyprovider to handle DNS queries. After some more research, I stumbled upon NETransparentProxyManager, could I use this instead in combination with NETransparentProxyNetworkSettings to selectively handle DNS queries for certain hostnames? My use case is this: Mac Client goes to "test.nonpublic.com" which does not exist within the public internet. (I will have a list of hostnames that should have their DNS requests intercepted) This DNS request should be intercepted and the request should be sent through an established web socket connection to be handled. All other DNS requests should not be handled by the application Note: I only want to deal with DNS queries. No other network traffic is of concern to me as of this moment. If this is the case, is there a code snippet you can provide that applies this configuration to NETransparentProxyManager? If not, could you advise on how I should proceed to implement the behaviour I want?

Sorry, what I meant was indeed NETransparentProxyProvider. In what ways can I selectively handle flows with NETransparentProxyProvider? How specific can I get with the configuration? For example, can I only handle flows which are DNS requests that contain certain hostnames?

Let me make sure I understand here; you are wanting to setup a point to point VPN and then have your VPN traffic from your client access a web server sitting behind the VPN server? That is correct If that is the case, the 10,000 foot answer here is that I suspect you have a routing issue in getting your packets from the utun interface on the server to route to the routing table that your web server has accessible to it This seems like a likely case in my opinion too. What do I need to add / edit in the routing table to get these packets to arrive at their destination (ie: the webserver)? If I open a browser and visit the webserver on the machine that the VPN Server is running, I see that traffic is generated on the en0 interface and that the webpage is being served if that is of any help

Update, I now have traffic (the SYN/ACK) being generated on the en0 interface on the VPN Server. The webserer can see the SYN packet and responds with a SYN/ACK accordingly. I was able to do this by having IP forwarding enabled using this command: sudo sysctl -w net.inet.ip.forwarding=1 Since the SYN/ACK is going to the en0 interface, my application is not able to grab it. How can I get the packet to go to the utun[x] interface that I created so that I can read from the interface and send the packet to the client?

Did you set filterPackets when you set up your filter provider configuration? Yes, I have. What else could be wrong? Also, I should be receiving all network packets correct?

To confirm, your provider starts? That is, you see that Started Packet Filter log message? Yes, my provider initializes and startFilter is called. I can see the Started Packet Filter log message. I do not see the Dropping Packet log message.

So can you walk me through how this digital identity is used? Apologies for the lack of information. Essentially we are developing a middlebox. We want to inspect and control HTTPS browser traffic. In order to do so we have a NETransparentProxyProvider intercept traffic. Our trusted root certificate would be used to generate site certificates that have the same fields as the certificates we receive from the server. In order for our "clones" to be trusted by browers our root certificate would need to be set to trusted since it issued them.

Hello again, it seems that on macOS Monterey 12.0.1 this prompt for a password is no longer required when running as a root daemon. Is this intended behaviour and can we expect this behaviour going forward with newer versions of Monterey? Also, in the case of macOS Big Sur, are there intentions to remove the requirement for user interaction for this API when running as a root daemon?