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.

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".

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?

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.

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.

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 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.

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

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.

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?

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.

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?

Done! TSI Follow-up: 745748241

Thanks for your reply. This goes along with my point above about using the NWHostEndpoint in the remote side of the connection. Are you unable to use this here? We use NWHostEndpoint to connect to the remote site without a problem (socket API: gethostbyname and connect). The problem is that this breaks Safari somehow. If you use the hostname provided by NEAppProxyTCPFlow do you still receive these errors in Safari: Exactly. That's the whole point! Can you please try to make your TransparentProxy sample to capture all flows from Safari and open a YouTube video? Safari console should be full of such errors. By the way, is there a publicly available sample of NEAppProxyProvider? We were unable to find anything.

Safari throwing these errors due to an altered origin IP does make sense if the client application in Safari has configured their site in this way. The problem is that when an extension processes Safari’s flows, IP address does not appear anywhere in NEAppProxyFlow API at all. From remoteEndpoint docs: https://developer.apple.com/documentation/networkextension/neappproxytcpflow/1406233-remoteendpoint If the flow’s corresponding socket was created using one of the high-level networking APIs such as URLSession or NSURLConnection, then the hostname property of the remoteEndpoint object contains the DNS name of the remote host. If the flow’s corresponding socket was created using the sockets API directly, then the hostname property of the remoteEndpoint object contains the IP address of the remote host. So, in our case it is DNS name only, there is no IP address and we cannot set or alter it in the extension. As for your questions, Do you have anything in place that would alter the remoteEndpoint delivered by the system for NEAppProxyFlow?  For example a system level proxy or a PAC proxy for certain endpoints that would have already altered the remoteEndpoint? No, we test on a clean system. These are flows that you are instructing your proxy to handle, correct? For the test scenario, the extension processes all TCP flows on the system and just "forwards" them to the original destinations. It acts like a transparent proxy and there is no an actual proxy sever involved. Do you have any other filtering rules in place that would cause the remoteEndpoint to show up as 0.0.0.0? No.