Avoiding my own flows in Transparent App Proxy

On MACOS Catalina, I have written the Transparent App Proxy and am able to redirect the flow to my application. That application in turn opens the flow to remote server . I want to avoid any processing on the traffic coming from this application which is connecting to same port as the original client application and hence falling into same rule and landing back in my handleNewFlow .


I am not sure how to ignore these flows originating from my own application . since returning NO from handleNewFlow closes that connection .

this appears to be a common problem with any proxy application . any pointers, API or mechanism which will help me ?

I am not sure how to ignore these flows originating from my own application . since returning NO from handleNewFlow closes that connection .

Right. Does using the NETransparentProxyNetworkSettings for excludedNetworkRules on specific address ranges restrict these flows in any way for you?


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
excludedNetworkRules will not work here since
1 ). for client : source ip would be localhost and some volatile port and connecting to server ip & port
2) for proxy. : source ip would be localhost and some volatile port and connecting to server ip & port

so no sure what rule to set here .

there is no provision to filter by process id. /. token /bundle id, etc.
so still not clear how to avoid these flows .

there is no provision to filter by process id. /. token /bundle id, etc.

Do you see the flow.metaData.sourceAppAuditToken here on these flows? If so, you could attempt to extract the bundle id from the originating app on the flow by starting down the path of SecCodeCopyGuestWithAttributes with kSecGuestAttributeAudit. Quinn wrote an excellent example of this here.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
I am also facing the same issue of getting into loop.

I am not clear about the method of using audit token from flow's metadata. If you have a working example, can you please share.

Is there any simple way of avoiding the capture of tcp flow coming from specific process(in our case it is launch agent).
Starting in macOS 11, Beta 10 it does not get easier to ignore flows that you do not want to handle by using the NETransparentProxyProvider and returning false to let the OS handle these flows. In Quinn's example if you are able to identify the bundle id with the flow.metaData.sourceAppAuditToken then this would be one way to approach identifying flows you want to ignore.

Note that the NETransparentProxyProvider is a new API in macOS 11, Beta 10.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Thanks Matt for your reply. I got the looping issue resolved.

I have a generic question on macOS network extension - transparent proxy provider.

Is it a must to implement transparent proxy provider as a system extension inside an app?

With this approach, we are observing 2 popups , one popup for system extension, one popup while adding VPN configuration (for monitoring network). The other issue is user can see the transparent proxy in the Network Preferences, which is weird. This is something different when compared to NKE behavior.

We are looking for ways to avoid these 3 things. Can we avoid above popups and proxy inside network preferences?

Before trying anything, I would like a guidance whether trying that approach worth or not.
We are thinking to try implementing transparent proxy provider inside a launchdaemon?

Can we implement transparent proxy provider inside a launchdaemon? or if system extension is the only option, then how can. we avoid above 2 popups and proxy visible in network preference?

Thanks Matt for your reply. I got the looping issue resolved.

No problem. Glad that worked out for you.

Is it a must to implement transparent proxy provider as a system extension inside an app?
With this approach, we are observing 2 popups , one popup for system extension, one popup while adding VPN configuration (for monitoring network). The other issue is user can see the transparent proxy in the Network Preferences, which is weird.

Yes. The container app is used as a mechanism to install the Network System Extension and to display to the user with these popups what is happening during this process.

Can we avoid above popups and proxy inside network preferences?

For a Transparent Proxy Provider, auto-allowing the Network Configuration prompt is not possible. This would be an enhancement request. To auto-allow the System Extension pop-up you would need to use MDM here.

Before trying anything, I would like a guidance whether trying that approach worth or not.
We are thinking to try implementing transparent proxy provider inside a launchdaemon?

A few issues off the top of my head: your Transparent Proxy Provider will need a container app for System Extension to be installed. The container app and Network System Extension for your NETransparentProxyProvider will also need a Sandbox and the App Sandbox just wasn’t designed for daemons.

Having said that your Network System Extension could communicate with a System Daemon, just not installed and run from one.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Matt,

You mentioned that "The container app and Network System Extension for your NETransparentProxyProvider will also need a Sandbox".
But in my sample, I have got a network system extension inside an app without sandbox. It is working as expected.
One point to note here - disabled SIP on my system. Does disabling SIP lift the sandbox requirement of app and network system extension?
I have couple of queries:
  1. Is there any way we can disable or grey out the connect/disconnect option for transparent proxy provider in network preferences?

  2. The transparent proxy provider is shown as VPN application in network preferences. Will this be impacted when other VPNs are installed and running on the system?

But in my sample, I have got a network system extension inside an app without sandbox.
It is working as expected.

Right. In a sample project there is nothing forcing you to a Sandbox on your container app or your Network System Extension. If you want to distribute your project via Developer ID or through the Mac App Store you will need to have both your container app and Network System Extension Sandboxed. I would also advise using a Sandbox during development to make sure you do not run into any "gotchas" when distributing.


One point to note here - disabled SIP on my system. Does disabling SIP lift the sandbox
requirement of app and network system extension?

No. As mentioned above, you can remove a Sandbox on a test project with SIP enabled.


Is there any way we can disable or grey out the connect/disconnect option for
transparent proxy provider in network preferences?

No. This is an Enhancement Request for NETransparentProxyProvider.

The transparent proxy provider is shown as VPN application in network preferences. Will this be impacted when other VPNs are installed and running on the system?

In my testing using a Transparent Proxy and a Packet Tunnel VPN at the same time have not shown to cause immediate issues. The best way to know for sure is to test your exact scenario(s).


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Avoiding my own flows in Transparent App Proxy
 
 
Q