Yes, outgoing connections are handled in handleNewFlow (created real connection, opened flow and forwarded data in both directions) and works - there are log records in Console. But incoming connections from hosts from "intercepted" networks doesn't work while TransparentProxy is running, and no records in Console about them (may be because they are incoming and TransparentProxy have nothing to do with them, but anyway they doesn't work)

Do you see the incoming connections reaching their local destination? The TransparentProxy in this case has a NENetworkRule setup for NETrafficDirectionOutbound connections. No, they doesn't reach my host. Connections to my host on another host just hang. And nothing in netstat on my host. If I stop transparent proxy, everything starts working as usual. If I specify another network in outbound rule, everything starts working as usual too.

Do you see the incoming connections reaching their local destination? The TransparentProxy in this case has a NENetworkRule setup for NETrafficDirectionOutbound connections. Sorry, may be I didn't understand question. Outgoing connections are okay - they works and reaches destinations. Incoming connections doesn't work when transparent proxy is active (as described in my previous message) and I'm connecting from host that matches NENetworkRule from this topic - connections hang.

This is worth a bug report. Please open a bug report with the following information, along with any logs or sample projects, and respond back with the Feedback ID. Reported, FB8486799

I found another bug in how Safari's outbound socket is created when TransparentProxy is running, and outbound address is IPv6. It is wrongly shown as 0.0.0.0:0 in Inspect -> Network tab, and the same in netstat. Commented in the same ticket. There are no such problems with Chrome-based browsers.

Hello! Any news on this issues? Actually there are three separate issues: 1) Incoming connections are broken as in this issue 2) Transparent proxy can't filter localhost (but NKI can) 3) Safari is creating connections with invalid address family when using TransparentProxy and shows 0.0.0.0:0 in filtering log, and tcp4 in netstat, for IPv6 connections Should I create separate feedback ID for them?

I found another example of bug that application shows 0.0.0.0 instead of IPv6 address. $ /usr/bin/ssh fa2.lamo.su The authenticity of host 'fa2.lamo.su (0.0.0.0)' can't be established. ECDSA key fingerprint is SHA256:dZsSQrUwwPgm/EZ8wGkuijpIEslPTg3NcfIEQgWLqiY. Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C Apple ssh also shows 0.0.0.0 instead of IPv6 addresses. But $ ~/homebrew/bin/ssh fa2.lamo.su The authenticity of host 'fa2.lamo.su (2a01:4f8:1c17:4e80::1)' can't be established. ECDSA key fingerprint is SHA256:dZsSQrUwwPgm/EZ8wGkuijpIEslPTg3NcfIEQgWLqiY. Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C Homebrew ssh works as expected. I guess that both Safari and Apple ssh may use the same network framework, that doesn't work correctly with NETransparentProxy and shows 0.0.0.0 instead of IPv6 addresses.

Deleted, last answer by topic starter is more informative description of that problem persists.

I created TSI number 754458218 and specified more examples of apps that are broken by this scheme.

Just installed 11.1 RC and the bug was still not fixed. :( So disappointing. Will we need to keep our "Big Sur workarounds HOWTO" for at least one release?

Hello! Are there any updates?

Hello! It is very important that SSH should be connected while no transparent network extensions are running in the system. Then I start network extension and just press a key in SSH, and voila: It is also reproduced with node.js with SSL. If I run the following code with link to large file: https = require('https') https.get('link_to_large_file'); And then start transparent proxy network extension, and in minute node.js will eat CPU too.

I actually already created the feedback: FB9125326 Also added information how to reproduce bug using "node.js" to it.

The interesting thing is that a more recent version of OpenSSH has a fix that properly detect this unexpected behavior Eventually, Apple SSH and libuv (nodejs) may adopt to this behaviour too... But it will not be an ideal solution, socket continues to behave in a way that usual socket doesn't, and there are may be other apps that doesn't expect this. :(

On Big Sur 12 beta 2 and 11.5 beta 4 issue is still reproducible with node.js. Almost all Electron apps including Signal messenger are affected. :(