NETransparentProxy breaks incoming connections

Hello!

I create NETransparentProxy with the following configuration:

Code Block
settings.includedNetworkRules = @[[[NENetworkRule alloc]
initWithRemoteNetwork:
[NWHostEndpoint endpointWithHostname:@"2000::" port:@"0"]
remotePrefix:3
localNetwork:nil localPrefix:0
protocol:NENetworkRuleProtocolTCP
direction:NETrafficDirectionOutbound]];

So, there is wildcard port and IPv6 network 2000::/3 (global unicast)

After this rule is created, any incoming connection from any IPv6 host will be dropped.
And when it is dropped, there is no any activity in AppProxyProvider or and NSLog of Network extension.

Is it a bug? Why it affects incoming traffic while NETransparentProxy may only have outbound rules?

Good old kernel extensions don't break incoming connections when diverting sockets.

I use Catalina but Big Sur users are also reporting this problem.

Replies

Apple's SSH sees the wrong remote address for some reason.

My point is that it's not just Apple's SSH, this is quite a serious issue actually. I suppose that it affects all apps that use new Apple networking API, and that's why Safari and Apple's SSH are affected, and Chrome or ssh from brew aren't.

For me this bug lead to Youtube being broken in Safari.

Here's what was going on:
  1. Safari "thinks" that all domains have the same IP address (0.0.0.0)

  2. Note that Youtube serves static content from *.googlevideo.com subdomains using HTTP2

  3. All these subdomains have the same wildcard certificate

  4. Points 1-3 (same IP, same cert, HTTP2) are enough for Safari to start using HTTP2 connections coalescing

  5. That leads to Safari sending HTTP2 requests to a wrong server completely breaking loading videos.

Having said that I believe it is not correct to say that using the Transparent Proxy API will break every app.

I admit I might have indeed exaggerated it a bit, but I still consider this a major (if not critical) bug.

I really hope that you're able to reproduce this issue with the example from @ngorskikh. If you think it makes sense for me to submit a TSI or Feedback or do anything else, please let me know.
There is a known issue that we are aware for loading Youtube videos over XHR with specific types of NENetworkRules. See my follow up here for an overview of the issue for and for an example of the NENetworkRules that do work with Youtube and do not work.

I have not been able to reproduce, nor have I seen instances in my testing of Safari flows being assigned the default route (0.0.0.0) with a TransparentProxy. There is mention on this thread of other flows (SSH) getting being assigned the default route, but that is something I simply have not had time to research.

@ngorskikh, please make sure that all of the information and steps to reproduce have been added to the bug report.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
It looks like for IPv6 there's already a workaround in place:
Code Block
➜ ~ /usr/bin/ssh fa2.lamo.su              
The authenticity of host 'fa2.lamo.su (0.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:dZsSQrUwwPgm/EZ8wGkuijpIEslPTg3NcfIEQgWLqiY.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no          
Host key verification failed.
➜ ~ /usr/local/Cellar/openssh/8.3p1/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])? no
Host key verification failed.

Note how Apple's SSH sees some probably synthesized IPv4 address when trying to connect to IPv6 host through a Transparent Proxy. To reproduce this, I've enabled IPv6 on my machine and added 2000::/3 to includedNetworkRules in my NETransparentProxyNetworkSettings

I'm also seeing synthesized IPv4 addresses in Safari inspector:
Code Block
Summary
URL: https://www.youtube.com/
Status: 200
Source: Network
Address: 0.0.0.198:443

Code Block
Summary
URL: https://www.google.com/
Status: 200
Source: Network
Address: 0.0.0.106:443


I can't see this "synthetic" IPv4 connection in netstat

Please note that if there's no IPv6 connectivity on user's machine, we go back to 0.0.0.0 issue.