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.

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.