Description Enterprise users are experiencing VPN resource access failures after upgrading to macOS Tahoe. Investigation indicates that configd (specifically IPMonitor) is incorrectly re-ranking network interfaces after a connectivity failure with probe server. This results in DNS queries routing through the physical network adapter (en0) instead of the VPN virtual adapter, even while the tunnel is active. This behaviour is not seen in previous macOS versions.
Steps to Reproduce:
- Connect to an enterprise VPN (e.g., Ivanti Secure Access).
- Trigger a transient network condition where the Apple probe server is unreachable. For example make the DNS server down for 30 sec.
- Observe the system routing DNS queries for internal resources to the physical adapter.
Expected Results The: VPN virtual interface should maintain its primary rank for enterprise DNS queries regardless of the physical adapter's probe status.
Actual Results: IPMonitor detects an UplinkIssue, deprioritizes the VPN interface, and elevates the physical adapter to a higher priority rank.
Technical Root Cause & Logs: The system logs show IPMonitor identifying an issue and modifying the interface priority at 16:03:54:
-
IPMonitor Detection: The process identifies an inability to reach the Apple probe server and marks en0 with an advisory:
Log snippet
2026-01-06 16:03:53.956399+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] configd[594] SetInterfaceAdvisory(en0) = UplinkIssue (2) reason='unable to reach probe server'
- Interface Re-ranking: Immediately following, IPMonitor recalculates the rank, placing the physical service ID at a higher priority (lower numerical rank) than the VPN service ID (net.pulsesecure...):
Log snippet
2026-01-06 16:03:53.967935+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 0. en0 serviceID=50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 addr=192.168.0.128 rank=0x200000d
2026-01-06 16:03:53.967947+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 1. en0 serviceID=net.pulsesecure.pulse.nc.main addr=192.168.0.128 rank=0x2ffffff
3.Physical adapter Is selected as Primary Interface: 2026-01-06 16:03:53.968145+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary IPv4 configd[594]: 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary DNS
- Packet Trace Evidence Wireshark confirms that DNS queries for enterprise-specific DNS servers are being originated from the physical IP (192.168.0.128) instead of the virtual adapter:
Time: 16:03:54.084
Source: 192.168.0.128 (Physical Adapter)
Destination: 172.29.155.115 (Internal VPN DNS Server)
Result: Connectivity Failure (Queries sent outside the tunnel)