Recently, we have observed that after upgrading to OS 15.4.1, some devices are experiencing network issues. We are using a Network Extension with a transparent app proxy in our product. The user encounters this issue while using our client, but the issue persists even after stopping the client app. This appears to be an OS issue. Below is the sytem logs. In the system logs, it says [C669.1 Hostname#546597df:443 failed transform (unsatisfied (No network route), flow divert agg: 2)] event: transform:children_failed @0.001s In scutil --dns, it says not reachble. DNS configuration resolver #1 flags : reach : 0x00000000 (Not Reachable) resolver #2 domain : local options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 301000 We need to restart the system to recover from the issue.

Hi Team, I'm trying to capture inbound traffic for DNS responses and have experimented with the following rules, but they did not work. NENetworkRule *dnsInboundTraffic = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:[NWHostEndpoint endpointWithHostname:@"0.0.0.0" port:@"53"] localPrefix:0 protocol:NENetworkRuleProtocolUDP direction:NETrafficDirectionInbound]; settings.includedNetworkRules = @[dnsInboundTraffic]; Could you please correct me if I'm making any mistakes while setting the rules?

Hi Team, I'm currently using a system extension with NETransparentProxyProvider (with root privileges). I want to support custom DNS (specific to domains) with a search domain to accommodate a single-level domain support. For this, I'm creating a new entry inside /etc/resolver/, using below command. sudo sh -c 'echo "domain corp.test.com\nsearch corp.test.com\nnameserver 9.9.9.9\nnameserver 9.9.2.2" > /etc/resolver/corp.test.com' The above command works fine for me when I execute it via the terminal, creating a new file inside the resolver as described below. So, when I access a single-label domain like https://test, it appends 'corp.test.com,' resulting in hitting the domain as https://test.corp.test.com. Furthermore, it selects either the DNS server 9.9.9.9 or 9.9.2.2. File: /private/etc/resolver/corp.test.com domain corp.test.com search corp.test.com nameserver 9.9.9.9 nameserver 9.9.2.2 File permission total 8 -rw-r--r-- 1 root wheel 80 Dec 5 18:20 corp.test.com scutil --dns resolver #8 domain : corp.test.com search domain[0] : corp.test.com nameserver[0] : 9.9.9.9 nameserver[1] : 9.9.2.2 flags : Request A records, Request AAAA records reach : 0x00000002 (Reachable) However, when I execute the same command within the extension using NSTask, it generates the new file but fails to work as per above. it creates below file File: /private/etc/resolver/corp.test.com domain corp.test.com search corp.test.com nameserver 9.9.9.9 nameserver 9.9.2.2 File permission total 8 -rw-r--r-- 1 root wheel 80 Dec 5 18:25 corp.test.com scutil --dns resolver #8 domain : corp.test.com search domain[0] : corp.test.com nameserver[0] : 9.9.9.9 nameserver[1] : 9.9.2.2 flags : Request A records, Request AAAA records reach : 0x00000002 (Reachable) I don't notice any difference in file permissions and in scutil --dns entry. even we tried running sudo killall -HUP mDNSResponder to refresh its records. Could you please suggest what might be the reason?