NETransparentProxy no longer working in Monterey beta 8

Question

Created Sep ’21

Replies 2

Boosts 0

Participants 2

Beginning with Monterey beta 8, our NETransparentProxy is no longer functioning. Its handleNewFlow never gets called with any flows while it is loaded - but while loaded, the OS doesn't send any traffic out the network interface either.

This is new (incorrect) behavior in beta 8 (or possibly beta 7...I don't have a system running it anymore to be able to check). It definitely is not happening on beta 6 (I do have a system running it still).

I have logged FB9625030 with details and sysdiagnose from both beta 6 (working) and beta 8 (broken). I am wondering if there is something we are missing that needed to change in the recent betas, or if there is an unintended regression in the OS.

Boost

Answer 1

Systems Engineer OP

Apple

Sep ’21

I just ran a quick test with macOS Monterey beta 8 (21A5534d) with Xcode 13.0 (13A233) and was able to receive flows for the NETransparentProxyProvider. Here are the set of NENetworkRule's that I am using:

let settings = NETransparentProxyNetworkSettings(tunnelRemoteAddress: "x.x.X.X")
settings.includedNetworkRules = [
    NENetworkRule(remoteNetwork: nil,
                  remotePrefix: 0,
                  localNetwork: nil,
                  localPrefix: 0,
                  protocol:.TCP,
                  direction: .outbound),
    
    NENetworkRule(remoteNetwork: nil,
                  remotePrefix: 0,
                  localNetwork: nil,
                  localPrefix: 0,
                  protocol:.UDP,
                  direction: .outbound),
    
]

Here's at least one recorded flow from Safari:

2021-09-30 20:15:11.093994-0700 0x77b6     provider received a new flow, flow: 0x600000f984c0 TCP com.apple.Safari[{length = 20, bytes = 0x5ab8a9d0fee2f73adfb8baabe4b2cc3d2bd4dcf0}] remote: x.x.x.x:443 interface en1
2021-09-30 20:15:11.101495-0700 0x77b6     new flow with bundle id com.apple.Safari is being claimed
2021-09-30 20:15:11.101548-0700 0x77b6     NEAppProxyFlow, flow: 0x600000f984c0 - (WILL be claimed) by the proxy.
2021-09-30 20:15:11.101610-0700 0x77b6     Flow Provider will handle new NEAppProxyTCPFlow, flow: 0x600000f984c0 - TCP com.apple.Safari[{length = 20, bytes = 0x5ab8a9d0fee2f73adfb8baabe4b2cc3d2bd4dcf0}] remote: x.x.x.x:443 interface en1
2021-09-30 20:15:11.101692-0700 0x7737     provider core will start new TCP flow, flow: 0x600000f984c0
2021-09-30 20:15:11.103829-0700 0x7737     provider core will start new TCP flow endpoint x.x.x.x:443, flow: 0x600000f984c0
2021-09-30 20:15:11.105392-0700 0x7737     provider core did start TCP flow, copier: 0, flow: 0x600000f984c0
2021-09-30 20:15:11.105801-0700 0x7737     (TCP) copier 0 connection did change state, state: p on queue: <...>
2021-09-30 20:15:11.105826-0700 0x7737     (TCP) copier 0 connection did change state, state: p
2021-09-30 20:15:11.106363-0700 0x7737     ##### (TCP) Copier - Preparing 0 #####
2021-09-30 20:15:11.106496-0700 0x7737     (TCP) copier 0 connection did change state, state: preparing
2021-09-30 20:15:11.106591-0700 0x7737     (TCP) copier 0 preparing state - remote endpoint: x.x.x.x:443 - path: satisfied (Path is satisfied), interface: en1, ipv4, dns - interface: No interface on queue: <...>
2021-09-30 20:15:11.120734-0700 0x77c9     (TCP) copier 0 connection did change state, state: r on queue: <...>
2021-09-30 20:15:11.120802-0700 0x77c9     (TCP) copier 0 connection did change state, state: r
2021-09-30 20:15:11.120833-0700 0x77c9     ##### (TCP) Copier - Ready 0 #####
2021-09-30 20:15:11.120860-0700 0x77c9     (TCP) copier 0 connection did change state, state: ready
2021-09-30 20:15:11.121502-0700 0x77c9     (TCP) copier 0 inbound will read
2021-09-30 20:15:11.121572-0700 0x77c9     (TCP) copier 0 outbound will read
2021-09-30 20:15:11.121759-0700 0x77b6     (TCP) copier 0 outbound did read, data count: 517
...

How do are your NENetworkRule's configured? THe bug report that you opened mentioned issues with a PAC and not a Network Extension. Is the PAC included in the environment that you seen the failure on?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

Toonetown OP

Sep ’21

I added the wrong FB ID - the correct one is FB9668079. I think I will still log the DTS incident and continue discussion there (sharing code snippets as needed, etc).

0