Hi! I've noticed that the IP_RECVIF socket option, i.e.: int y = 1; setsockopt(fd, IPPROTO_IP, IP_RECVIF, &y, sizeof(y)); does not seem to work if the socket is proxied by a NETransparentProxyProvider type network extension: there's no ancillary data in messages received with recvmsg. As soon as I disable the network extension, recvmsg starts returning ancillary data containing the interface name. This seems to break some applications which rely on IP_RECVIF in the presence of a transparent proxy, making it, in fact, not transparent. One such example is Apple's own libresolv, which relies on IP_RECVIF and breaks if there's no ancillary data in the recvmsg result. I don't think that this is the intended behaviour, since IPV6_PKTINFO seems to work fine. I've filed a bug report (FB17586550) about this, however, I would greatly appreciate if someone could point me in the direction of a workaround.

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.

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.

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