We need your assistance as we are currently facing an issue without a workaround for users on macOS 15.4 and 15.5.
FeedbackID: FB17547675
The problem has been observed on macOS versions 15.4 and 15.5. Apple has acknowledged this issue and confirmed that it is fixed in the macOS 15.6 beta. Although we tried to reproduce the issue in our environment, it did not occur, even on macOS 15.5. Therefore, we cannot verify if the fix in macOS 15.6 beta resolves the problem.
We are actively working to identify an appropriate workaround for users on macOS 15.5. Some users have reported a failure to obtain an IP address over Wi-Fi, possibly due to a DHCP failure.
As a temporary solution, we added logic to restart Wi-Fi programmatically when either an APIPA address (169.254.x.x) or no IPv4 address is detected on the active interface. However, restarting Wi-Fi does not always resolve the issue, and the device may still fail to obtain an IP address over Wi-Fi or Ethernet.
Could you advise if there is a reliable method to detect DHCP failure and recover the device from this state? Also, any idea, how we can reproduce this scenario in our machine?
Below is the failure.
default 2025-06-27 10:07:57.055003 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:07:57.055269 -0700 configd DHCP en0: status = 'no server'
default 2025-06-27 10:08:23.336215 -0700 airportd WiFiUsageBssSession:: ChannelAfterRoam=0; ChannelAtJoin=36; FaultReasonApsdTimedOut=0; FaultReasonArpFailureCount=0; FaultReasonBrokenBackhaulLinkFailed=0; FaultReasonDhcpFailure=0;
default 2025-06-27 10:08:23.367852 -0700 configd DHCP en0: status = 'media inactive'
default 2025-06-27 10:08:23.367909 -0700 configd DHCP en0: INACTIVE
default 2025-06-27 10:08:23.988565 -0700 configd DHCP en0: status = 'media inactive'
default 2025-06-27 10:08:23.988703 -0700 configd DHCP en0: INACTIVE
info 2025-06-27 10:08:23.988852 -0700 configd DHCPv6 en0: Inactive
default 2025-06-27 10:08:35.656415 -0700 configd DHCP en0: status = 'network changed'
default 2025-06-27 10:08:35.656817 -0700 configd DHCP en0: INIT
default 2025-06-27 10:08:35.656821 -0700 configd DHCP en0: supplying device type 'Mac'
info 2025-06-27 10:08:35.656934 -0700 configd DHCP en0: busy
default 2025-06-27 10:08:35.657351 -0700 configd DHCP en0: INIT waiting at 0 for 1.358613
info 2025-06-27 10:08:35.657404 -0700 configd DHCPv6 en0: Inactive
default 2025-06-27 10:08:37.019229 -0700 configd DHCP en0: INIT waiting at 1.36206 for 2.113913
default 2025-06-27 10:08:39.136955 -0700 configd DHCP en0: INIT waiting at 3.47937 for 4.462224
default 2025-06-27 10:08:43.602229 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:08:43.603143 -0700 configd DHCP en0: INIT waiting at 7.94533 for 8.128784
default 2025-06-27 10:08:51.735532 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:08:51.735846 -0700 configd DHCP en0: INIT waiting at 16.0786 for 8.749985
default 2025-06-27 10:09:00.488315 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:09:00.488550 -0700 configd DHCP en0: INIT waiting at 24.8313 for 8.496864
default 2025-06-27 10:09:08.988284 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:09:08.988310 -0700 configd DHCP en0: reported address acquisition failure symptom
default 2025-06-27 10:09:08.988579 -0700 configd DHCP en0: INIT waiting at 33.3312 for 8.300735
default 2025-06-27 10:09:17.294478 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:17.294485 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:17.295454 -0700 configd DHCP en0: INIT waiting at 41.6373 for 8.798768
default 2025-06-27 10:09:26.096673 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:26.096688 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:26.097553 -0700 configd DHCP en0: INIT waiting at 50.4394 for 8.807943
default 2025-06-27 10:09:34.909050 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:34.909054 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:34.909375 -0700 configd DHCP en0: INIT waiting at 59.2517 for 8.877971
default 2025-06-27 10:09:43.792458 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:43.792464 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:43.793641 -0700 configd DHCP en0: status = 'no server'
info 2025-06-27 10:09:43.794145 -0700 configd DHCP en0: not busy
DNS failure
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
Route table
Destination Gateway Flags Netif Expire
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#14 UCS en0 !
169.254.160.160/32 link#14 UCS en0 !
224.0.0/4 link#14 UmCS en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0
255.255.255.255/32 link#14 UCS en0 !
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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,
The Messages app is not working in the latest macOS Sequoia 15.0.1. We are unable to send messages or sync them when the VPN/TransparentAppProxy is connected.
It was working fine in macOS 15.0 and earlier.
A few users have reported the issue here: https://discussions.apple.com/thread/255802764?sortBy=rank
Hi Team,
Is there a way to disable secure DNS in macOS that is set at the OS level, like 8.8.8.8, which supports secure DNS on ports 443 and 853?
Hi Team,
We are trying to set MDM with NETransparentProxyManager to auto-approve the proxy, but it did not work.
We have tried the below Apple document for NETransparentProxyManager.
https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy.
Attached is the config file.
ApplicationProxy.VPN.mobileconfg.txt
could you please suggest how to configure NETransparentProxyManager via MDM?
Topic:
App & System Services
SubTopic:
Networking
Tags:
System Extensions
Device Management
Network Extension
Hi Team,
We are using the transparent app proxy in macOS and resolving DNS queries using DNSServiceQueryRecord in the TAP process.
According to the documentation, when passing the interfaceIndex as 0, it should be queried on all interfaces, and based on IP rules, it assigns the query to that particular interface.
However, when we pass 0, it does not query any of the interfaces. We need to provide the specific interface index.
HI Team,
We have recently observed a network issue, followed by device hang-ups when users come out of sleep while using the Transparent app proxy provider in Sonoma 14.4. and users are required to restart the system to resolve the problem.
In the client logs, we observed that State:/Network/Global/IPv4 does not have any PrimaryInterface and there is no internet connectivity, although the internet works fine on other devices.
this issue start coming in sonoma 14.4 and happen with Transparent app proxy provider.
We are currently unable to pinpoint the exact issue. Are there any known issues with Sonoma 14.4?
Hi Team,
Im trying to disable the option to change the status of the Transparent Proxy enable/disable but there is no API which works in NETransparentProxyManager.
Could you suggest, how to disable the option to change the status of the Transparent Proxy enable/disable? We want to disable it so that no one can modify it from the settings.
This option is coming in Network -> Vpn & Filters
I observed that some other providers disabled it in the "Network -> VPN & Filters" settings.
Hi Team,
In Sonoma, we have observed NIMLOC DNS queries originating from the utun interface with identical destination and source addresses, causing a loopback within utun. How should these DNS queries be handled?
This issue does not occur in Ventura. Please refer to the attached screenshot.
Hi Team,
We are using NETransparentProxyProvider and have observed that AirDrop is not functioning.
I attempted to utilize protocolConfiguration in NETransparentProxyManager as mentioned below.
manager.protocolConfiguration?.excludeLocalNetworks = true;
but it did not work.
Could you please provide guidance on how to exclude local network traffic in NETransparentProxyProvider?
Hi Team,
We are using NETransparentProxyProvider, and we have observed that whenever we set setNetworkInterface with NENetworkRule, it always generates the DNS query even if the TTL time has not passed.
However, when I stop the NETransparentProxyManager using stopVPNTunnel and set setNetworkInterface as nil, it will not re-issue the DNS query until the DNS TTL time has passed.
We've recently noticed frequent crashes on the macOS system after an OS update when using the system extension with NETransparentProxyProvider. Below are the crash logs that appear in a pop-up after the machine starts.
I'm having difficulty understanding the exact point at which it crashes, and it shows my process below.
Panicked task 0xfffffe2d0a36abf8: 8190 pages, 143 threads: pid 9134: com.xxxx.na Panicked thread: 0xfffffe236ea13010, backtrace: 0xfffffe67858d2b80, tid: 337348
Detailed logs attached.
system_cash_log.txt
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?
Hi Team,
I am utilizing the nw_parameters_create_secure_tcp in Objective-C to establish a TCP connection. However, I would like the connection to go through a specific utun interface.
I attempted to use the following method for binding:
nw_parameters_require_interface(nw_parameters_t parameters,
_Nullable nw_interface_t interface);
Unfortunately, I haven't found any API that can convert a utun interface name or index to an nw_interface_t object. Both nw_interface_create_with_index and nw_interface_create_with_name are private methods.
I also tried using nw_path_monitor_set_update_handler and nw_path_enumerate_interfaces, but they did not return the utun interface.
Could you please suggest how I can obtain the utun interface as an nw_interface_t?
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?