For example, the rule can be like this: NENetworkRule(remoteNetwork: nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: NETrafficDirection.outbound) It's very easy to reproduce. Just open a persistent TCP connection like SSH. Run a simple transparent proxy. Observe that SSH connection is broken. do you have the flow copying process in place to pickup and handle these connections? Yes, but this logic applies to the new connection only. Correct? How is it possible to do this for the existing ones?

Yes, existing connection may see interruptions and may have to be restarted. Is that what you are seeing too? Yes, this is what we see and this is a concern. So for example, if you establish SSH connection before AppProxy is activated, this existing SSH connection gets disconnected. Is this expected? If so, this is not optimal.

OK, so this is the expected behavior. That's bad because there are a lot of scenarios when connections should stay alive when AppProxy starts. I used SSH just as an example. Is it possible to submit this as a feature request to Apple?

Thanks for looking into this. I have submitted Feedback ID FB8742532. As for the work around, It can work only for isolated cases. If we need to serv all ports, we cannot create so many rules.

Please retry this with the update to macOS Big Sur Beta 10. I confirm the problem is solved now! Thanks!

Thank you very much for this hint! We are still testing but it seems that this update solves all the problems. By the way, this change was not rendered in the documentation. We have only found this in the source code comments.

Right. I did notice that as well. This would be an opportunity to open an enhancement request to further document this. Please respond back with the feedback ID. Done. Feedback ID is FB8829962.

Thank you for the help! This function works perfectly. What do you plan to do with this pid?  We use it to get process name that opens the flow. Normally we use sourceAppSigningIdentifier, but it is empty for non-signed programs. Some users still have them.

I have submitted TSI 753464789. It turned out that the problem happens when any NETransparentProxyProvider and NEFilterDataProvider run together on the system (same app or not). The problem persists in Big Sur 11.1 beta as well.

Hello, I guess we suffer from the same problem too (TSI 753464789). Apparently, that besides Safari websockets, it affects built-in ssh client if connected by hostname (broken pipe error) and any client program that uses NSStream/CFStream! Console may give errors like "TestNSStream[1545:26660] SocketStream write error [0x10060b360]: 1 32" Can you please confirm this with your tests and update your FB if appropriate?

Yes, this is disappointing. Safari WebSocket and https://developer.apple.com/forums/thread/666894 (FB8925105) are affected by the same problem. When the problem happens, Console outputs the following messages. When using over HTTPS: default 02:48:18.529584-0800 com.apple.WebKit.Networking CFNetwork SSLHandshake failed (-9810) error 02:48:18.529628-0800 com.apple.WebKit.Networking TCP Conn 0x7fbabecf04e0 SSLHandshake failed (-9810) default 02:48:18.531516-0800 com.apple.WebKit.Networking TCP Conn 0x7fbabecf04e0 canceled But with HTTP we see the underlying problem: error 02:46:23.243727-0800 com.apple.WebKit.Networking SocketStream write error [0x7fbabed57fc0]: 1 32 default 02:46:23.244424-0800 com.apple.WebKit.WebContent WebSocketChannel 0x10906b3d8 fail() reason='<private>' default 02:46:23.245953-0800 com.apple.WebKit.Networking TCP Conn 0x7fbabed57fc0 canceled Please notice "SocketStream write error [0x7fbabed57fc0]: 1 32". Error 32 is "broken pipe".

Thanks for the info. I hope it will be fixed soon. Obviously if your use case is to run a NEFilterDataProvider and a NEProxyTransparentProvider in tandem then this is a very slim workaround, I think that the tandem usage within the same app is a rare case. What is much more frequent and confusing is a conflict between two apps from independent vendors.

Done. TSI 756325646 created. Thanks.

I confirm that we use NETransparentProxyProvider and return FALSE from the callback. So, this should not affect the FaceTime in any way. I have submitted bug FB9002173. Thanks!

We have attached the sysdiagnose report to FB9002173 as requested. (Apparently Feedback Assistant had some problems but I hope that the file was uploaded correctly).