There is no way to do that, but it seems like a perfectly reasonable enhancement request. Please post your bug number, just for the record. Thanks for the suggestion! I've filed FB11655901.

Hi! Just wanted to mention that I've also bumped into this exact issue (duplicate queries to different DNS servers), although I'm NOT trying to filter all DNS traffic: I was able to reproduce DNS queries "leaking" past my tunnel even when matchDomains in my NEDNSSettings contains just a few specific domains that I want to be resolved through the tunnel. In my case, this seems to only reproduce in third-party apps, Safari for example doesn't exhibit this behaviour. I've filed a bugreport: FB9126588 and attached a simple reproducer app and tunnel to it.

Yep, tried adding rules for either/both 127.0.0.1/32 and ::1/128, with specific ports and zero port: no luck. I'm seeing something like this in the Console: [Extension com.i.love.apple.APIs.NEService]: provider set tunnel configuration to tunnelRemoteAddress = 9-char-str includedNetworkRules = ( { matchRemoteEndpoint = ::1.0 matchRemotePrefix = 128 matchProtocol = 3-char-str matchDirection = 8-char-str appliesToLoopback = NO }, { matchRemoteEndpoint = ::1.443 matchRemotePrefix = 128 matchProtocol = 3-char-str matchDirection = 8-char-str appliesToLoopback = NO }, { matchRemoteEndpoint = 127.0.0.1:0 matchRemotePrefix = 32 matchProtocol = 3-char-str matchDirection = 8-char-str appliesToLoopback = NO }, { matchRemoteEndpoint = 127.0.0.1:443 matchRemotePrefix = 32 matchProtocol = 3-char-str matchDirection = 8-char-str appliesToLoopback = NO }, ) ... I think it might have something to do with appliesToLoopback = NO, though I'm not quite sure...

Hi, @meaton! Is there any news regarding this issue? I can still reproduce on macOS 11.2 (20D64).

@dverevkin Hi! Could you please submit your patch or open a bug report with what you could find out to Dart? I've looked through their GitHub issues and got the impression that the Dart developers don't have a clue what's happening or how to fix it, while a few people are having this exact issue in different circumstances.

Hi, @meaton I stand corrected; Initially I was under the impression that any kind of network extension is affected, but after careful checking, it's only NETransparentProxyProvider that is causing trouble. The included sample always returns NO from handleNewFlow:: (BOOL)handleNewFlow:(NEAppProxyFlow *)flow { 		return NO; 		// commented code omitted } , so it's safe to assume that any attempt to handle this flow is actually the incorrect behaviour of the API. This also means that only macOS 11 is affected (unless NETransparentProxyProvider has been ported to Catalina as well).