I'm having a problem developing a "Transparent Proxy"-type network extension. The problem started with Big Sur. Everything seems to work on Catalina. Steps to reproduce: Disable (set link-local only) IPv6 on your network interface. Start a simple TransparentProxy network extension that forwards IPv4 TCP traffic (I've attached an example to feedback FB8690357). Open Mail.app and try to add a Yahoo account. Login either fails immediately with "Network connection timed out" or shows an error screen. P.S. QQMusic (an app from AppStore) also doesn't work on BigSur when network extension is active. It receives responses from the server proxied by the extension, but fails to display them for some reason. Browsing with Chrome and other network usage seems to work as normal.

Hi! I've been developing a transparent proxy network extension by extending NEAppProxyProvider, and later NETransparentProxyProvider when it became available. Both of them seem to have the same issue where loopback connections (i.e. connections to localhost, 127.0.0.1, ::1, etc.) can't be intercepted. Is this a deliberate decision or a bug? Is there a way I can work around this to filter loopback connections with my transparent proxy?

Hi! I'm developing a transparent proxy network extension using NETransparentProxyProvider. It looks like connections from mDNSResponder are not bypassed when returning NO from handleNewFlow: of NETransparentProxyProvider, and are terminated instead. Symptoms are non-functional DNS-over-HTTPS (installed through a .mobileconfig) when there's an active network extension which bypasses all traffic (always returns NO from handleNewFlow:). Solved by actually filtering flows from com.apple.mDNSResponder instead of bypassing them. I've filed FB8895063 with details and a sample app, but haven't gotten any answer yet; duplicating here for visibility. I've also got a suspicion that bypassing flows by returning NO from handleNewFlow: also leads to problems with other apps besided the mDNSResponder, since I've seen intermittent failures in apps that are not filtered by my network extension when it is active.

Any kind of network extension, when active, even when it doesn't actually interfere with the network traffic (e.g. always returning NO from handleNewFlow: of NETransparentProxyProvider), seems to break the Flutter package manager: Running "flutter pub upgrade" in flutter_repro...           ⣽Unhandled exception: Bad state: Future already completed #0   _AsyncCompleter.complete (dart:async/future_impl.dart:43:31) #1   _NativeSocket.startConnect.<anonymous closure>.connectNext.<anonymous closure> (dart:io-patch/socket_patch.dart:682:23) #2   _NativeSocket.issueWriteEvent.issue (dart:io-patch/socket_patch.dart:1102:14) #3   _NativeSocket.issueWriteEvent (dart:io-patch/socket_patch.dart:1109:12) #4   _NativeSocket.multiplex (dart:io-patch/socket_patch.dart:1130:11) #5   _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:168:12) I've managed to reproduce this with a sample network extension project and filed a feedback FB8952020. Any thoughts on how to work around this issue would be appreciated.

Hi! I've been developing a transparent proxy network extension and up until macOS 11.3 my extension could proxy loopback connections (i.e. connections to 127.0.0.1 or ::1). In 11.3 this stopped working (handleNewFlow is not called for such connections at all). I've filed FB9093112 about it but there's been no activity for a couple of weeks. A workaround suggestion would be much appreciated.

Hello. I'm developing a transparent proxy network extension by extending NETransparentProxyProvider. How can I get the original socket's options, i.e. what the app set using setsockopt() calls, from an NEAppProxyFlow? I'm particularly interested in the value of SO_KEEPALIVE, so I can enable keep-alives on my proxy's outgoing socket if they were enabled on the socket being proxied. I got as far as -[NEAppProxyFlow setMetadata:] -> nw_parameters_copy_default_protocol_stack(nw_parameters_t) -> nw_protocol_stack_copy_transport_protocol(nw_protocol_stack_t), which returns an object of type nw_protocol_options_t, but there are no accessor functions to retrieve the actual values from it.