macOS: Only one DNS Proxy NSYSEXT allowed?

Question

Created Jul ’22

Replies 4

Boosts 0

Participants 2

A client is seeing this behavior in their fleet. They have a 3rd party DNS Proxy and when that is loaded our DNS Proxy is immediately sent a stop message. I saw this behavior mentioned in another thread, but I've not been able to find an official stance on this from Apple. So is this expected behavior? This was observed on macOS 12.4 and 12.3 for both Apple Silicon and Intel.

Thanks.

p.s. I can understand the restriction, but our client is requesting further information. As they would like both proxies running.

Boost

Answer 1

Systems Engineer OP

Apple

Jul ’22

So is this expected behavior?

I have never tested with multiple NEDNSProxyProviders running at the same time, but I have tested with multiple NETransparentProxyProviders and likewise a NEDNSProxyProvider and NETransparentProxyProvider running at the same time and those cases do work. What logs are you seeing here when the stop message is sent to your provider?

0

Answer 2

bbergstrand OP

Jul ’22

Thanks for the reply Matt, here are the logs from the client:

112022-06-13 12:48:20.573425-0400 0x3d35     Default     0x0                  1166   0    com.uptycs.kringle.daemon: (NetworkExtension) [com.apple.networkextension:] (0): Creating a new flow director
122022-06-13 12:48:20.573623-0400 0x3d35     Default     0x0                  1166   0    com.uptycs.kringle.daemon: (NetworkExtension) [com.apple.networkextension:] [Extension com.uptycs.kringle]: Calling startProxyWithOptions with options 0x0
132022-06-13 12:48:20.573639-0400 0x3d35     Default     0x0                  1166   0    com.uptycs.kringle.daemon: [com.uptycs.kringle:dns-proxy] start
142022-06-13 12:48:20.576279-0400 0x3d35     Default     0x0                  1166   0    com.uptycs.kringle.daemon: [com.uptycs.kringle:dns-proxy] ready
...
2022-06-13 12:48:28.222215-0400 0x3cfa     Default     0x0                  158    0    sysextd: [com.apple.sx:XPC] client activation request for com.cisco.anyconnect.macos.acsockext
172022-06-13 12:48:28.264605-0400 0x3dc4     Default     0x0                  262    0    nesessionmanager: (NetworkExtension) [com.apple.networkextension:] Clearing 42C1466A-D643-4CCB-9B29-A0FDF2B57F03 from the loaded configurations
182022-06-13 12:48:28.275395-0400 0x3dc6     Default     0x0                  262    0    nesessionmanager: [com.apple.networkextension:] <NESMServer: 0x7ff0b3d047b0>: Deregister DNS Proxy Session: NESMDNSProxySession[Primary Tunnel:Uptycs Protect DNS Proxy:42C1466A-D643-4CCB-9B29-A0FDF2B57F03:(null)]
192022-06-13 12:48:28.275411-0400 0x3bcc     Default     0x0                  262    0    nesessionmanager: [com.apple.networkextension:] Registering session NESMDNSProxySession[Primary Tunnel:Cisco AnyConnect Socket Filter:FA292875-ADE4-4304-9423-E4527401CBAA:(null)]
202022-06-13 12:48:28.276187-0400 0x3d6a     Default     0x0                  1166   0    com.uptycs.kringle.daemon: (NetworkExtension) [com.apple.networkextension:] [Extension com.uptycs.kringle]: Calling stopProxyWithReason because: Configuration was disabled
212022-06-13 12:48:28.276190-0400 0x3d6a     Default     0x0                  1166   0    com.uptycs.kringle.daemon: [com.uptycs.kringle:dns-proxy] stop: 9

You can see from the logs that our DNS Proxy (com.uptycs.kringle.daemon) is started and then ~8 seconds later the Cisco NSYSEXT is started and our Proxy is stopped with code 9 (NEProviderStopReasonConfigurationDisabled). The Cisco NSYSEXT contains a socket filter and a DNS proxy. Our SYSEXT also contains a socket filter and a DNS proxy and only the DNS proxy is being stopped.

0

Answer 3

Systems Engineer OP

Apple

Jul ’22

Thank you for the logs and the additional context. Just to try and narrow this down, if you only try and start the NEDNSProxyProvider, and not the NEFilterDataProvider or any other VPN provider that may be on the system, does this change the outcome any?

0

Answer 4

bbergstrand OP

Jul ’22

Hi Matt, yes if no other NSYSEXT is on the system then there are no problems. We are only seeing this issue with this particular client. So far no other client is using another NSYSEXT. In addition, we are not able to reproduce the issue internally (again with no other NSYSEXTs).

0