macOS Sonoma cannot resolve short hostnames (no dots) when there is an active interface of NETransparentProxyProvider type. I have submitted a report FB13288727, but maybe I am missing something and there is a way to fix this from our NETransparentProxyProvider code? Normally, when you specify the search domain "example.net", the system resolver automatically adds it to the short hostnames like "testhost" (no dots). So the resulting query is "testhost.example.net". https://support.apple.com/en-il/guide/mac-help/mh141272/mac Starting from macOS Sonoma when there is an active interface of NETransparentProxyProvider type, the system resolver tries to resolve using only the first domain from the list. Also it does not try to resolve the hostname as it is (without the search domain). What makes this bug fatal is that Sonoma automatically adds a hidden entry like "0.5.168.192.in-addr.arpa" in the search domain list. So it tries to resolve shorthostname.0.5.168.192.in-addr.arpa, fails and does not try without the domain. So the resolution of all short hostnames always fails. It could be easily tested with a command like "ping store" and Search Domain "apple.com" Pre Sonoma versions: ping store PING store.apple.com (23.14.139.109): 56 data bytes... Sonoma: ping store ping: cannot resolve store: Unknown host In reality, it tries to resolve store.0.5.168.192.in-addr.arpa and fails. It does not try to resolve store.apple.com at all. This can be seen in the traffic to the DNS server (UDP port 53).

Hello, Our company is using NEAppProxyProvider in one of our applications. We have found that when the extension is working many sites are broken in Safari. For example, Safari cannot play any video on YouTube. In Safari dev console we see multiple errors like this: [Error] Origin <URL> is not allowed by Access-Control-Allow-Origin. [Error] XMLHttpRequest cannot load <URL> due to access control checks.   Further investigation has revealed that when the extension is working, Safari cannot get the IP of the target host (rendered as "-" or 0.0.0.0). Apparently, this breaks Safari logic that processes Access-Control-Allow-Origin. When the extension is not active, Safari works properly. The problem persists on Catalina and Big Sur with any Safari version including Preview. Chrome does not have this problem and works properly when the extension is active. So my question is: How can we set remote endpoint IP address for a flow using the API? Alternatively, this can be fixed on the Safari side. I can file a bug report or TSI. Thanks!

If handleNewUDPFlow of NEDNSProxyProvider returns false, the flow (DNS request) is terminated. Is there a way to make the system take care of it like in the case of NETransparentProxyProvider that returns false? Right now, our extension has to process all DNS flows while we need only a limited set. If it could act like NETransparentProxyProvider, it would significantly reduce the overhead and even could make DoH/DoT settings work for bypassed requests. Another question, Is there a way to know the hostname from the DNS request at the moment when handleNewUDPFlow callbacks gets called? Thanks!

In our NETransparentProxyProvider we use SecCodeCopyGuestWithAttributes to get information about the flow as suggested here here. We have faced an unexpected problem with this approach. Apparently, SecCodeCopyGuestWithAttributes has to deal with sandbox when working with the attributes of other programs. That’s OK when programs are located in /Applications. But some programs including built-in ones like /usr/libexec/routined are in other locations. So, when SecCodeCopyGuestWithAttributes is called for them, sandbox just kills the network extension completely! 2021-06-04 09:10:47.927841+0800 0x4cd Error 0x0 147 0 sandboxd: [com.apple.sandbox.reporting:violation] Sandbox: com.initex.proxi(897) deny(1) file-read-data /usr/libexec/routined Violation: deny(1) file-read-data /usr/libexec/routine Is there a way to fix this? For obvious reasons, the com.apple.security.temporary-exception.files.absolute-path.read-only trick does not work because the path is not known. I think, this also creates a security risk. We saw a case when a program with a non-standard executable path just stopped network extension of a well known antivirus!

For each flow that gets to NEAppProxyProvider via handleNewFlow we can get metaData. metaData has sourceAppAuditToken. Is it possible to use it to get PID or user ID?

Just wanted to draw some attention to the problem caused by NETransparentProxyProvider start. It breaks all existing TCP connections which is not good. 2. UDP "connections" just hang. This causes a lot of troubles for UDP based apps like VPNs, streaming, etc. Unlike TCP, UDP apps are not designed to recreate UDP socket to clear the problem so users have to restart the apps manually. FB8969320 3. Any running instance of the built-in SSH client hangs on NETransparentProxyProvider start and begins to unitize 100% of CPU. This is very confusing and annoying for the users. FB9070195 All these problems persist in Big Sur 11.4 Beta. Are there any plans to fix them? I can provide more info if needed. Thanks, Sergey

Our product used NKE to proxy a limited set of selected programs and connections. Now, we are rewriting it to NEAppProxyProvider. It seems that this API has a major problem. We have not found a way to proxy only selected programs and/or make filtering decisions dynamically. It seems like the rules for NEAppProxyProvider can only be set on VPN start and this does not support per-program rules at all. Is this correct? This is especially strange because NEFilterDataProvider (no traffic modification) can work with NEFilterNewFlowVerdict which allows to make flow decisions dynamically. In contrast, handleNewFlow of NEAppProxyProvider returns BOOL (reject or process). So, we have to process all flows. And if a flow has to stay intact (the vast majority of cases) we have to manually replicate it. Effectively, this forces all connections on the system to go through our app while we need only a few. This has a very bad impact on the network performance and compatibility with other products (coexistence is impossible). So is there a way to work with only a limited set of flows with NEAppProxyProvider like with NEFilterDataProvider?

Each time when AppProxy extension is running, FaceTime fails to make a call using iPhone connected with Mac Book. It displays the following error: Your iPhone and Mac must be on the same Wi-Fi network. The console log contains a message that is likely related to the problem: error     14:33:53.710813+0300 identityservicesd - [IDSUDPLink _sendBytesArray:lengthArray:arraySize:localInterfaceIndex:localAddress:destinationAddress:trafficClass:DSCP:]:472 sendmsg(53B) failed errno=22 default  14:33:53.710865+0300 identityservicesd send binding response failed with UnknownError The problem happens if AppProxy just bypasses all TCP and UDP flows by returning FALSE from the callback. So the flows should be handled by the system.

It seems that App Proxy (NETransparentProxyProvider) cannot start VPN (startTunnel / startVPNTunnel) when there is no an active network connection on the system. This includes adapters with self-assigned IP addresses that can actually perfectly work in some scenarious like ad-hoc Wi-Fi. Is this an expected behavior? Is there a workaround?

Hello, It seems that if there is a Transparent Proxy running on the system, all calls to listen() function of socket API fail with an error. This affects any TCP socket of any process. Steps to reproduce: Run a Transparent Proxy with the following rules: NENetworkRule(remoteNetwork: nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: NETrafficDirection.outbound) 2. Observe that listen() does not work anymore. It can be tested with netcat tool: % nc -vv -l 5555   nc: listen: Protocol wrong type for socket

We have noticed a strange problem when two apps that use Network Extensions (AppProxy and Filter) run in the same time. When this happens, TCP connection of any client app that uses a new network API like Safari or ssh breaks unexpectedly. ssh gives "write: Broken pipe" error. (The connection is established but it breaks on the first write). If ssh connects using IP address instead of hostname the problem does not occur! Please note that AppProxy (NETransparentProxyProvider::handleNewFlow) just returns false (bypass the flow). The filtering extension does not block the flow as well. Is it a known problem? If no, I can provide more info.

Our product uses NETransparentProxyProvider in the system extension. We have discovered that some apps (e.g. FaceTime) completely bypass our filter even if it is set to catch all. Is it a bug or an expected behavior? We have not found any reference to this in the documentation.

Hello, We have found out that after enabling an AppProxy System Extension, all existing TCP connections that match the filtering rules halt and need to be reopened by client apps. Is it expected behavior? It would be much better if the existing connections could continue to work as if with the legacy NKE.