I created a Suggestion feedback ticket with number FB7573775 that suggests the AppProxyProvider be able to not proxy a flow but allow the flow to continue.

I can confirm that in my testing, eskimo is right. I was unable to see the local port until data passed through the flow.

Borrowing heavily from AppCommunication in the Filtering Network Traffic, I was able to get XPC communication between the container app and the network extension.One of our apps is an XPC broker that does some security checks (to see if processes are signed properly) before facilitating the XPC connection. So all of the XPC Service building and Client connecting code is in helper classes that faciltate that brokerage. I need to get at least one of these apps (preferably the network extension itself) to communicate to the XPC broker and communicate to another app that is not the container app.Thanks for your help.

Yes, I am using "app" in the general sense. They are a combination of apps and bundles that are either LaunchAgents or LaunchDaemons, or started from those binaries. One of the LaunchDaemons is responsible for launching a majority of the other processes depending on licensing and features. Nothing has to be double-clicked by the user.

I'm not against using an App Group if that is what is needed. All the documentation I have seen says that App Groups are for sandboxed apps, and we don't use the sandbox. I have no idea of what an App Group is or how to use an App Group. I'm confused why I need to use App groups to have two non-sandboxed apps/binaries/processes to communicate.