Fake-IP, split-DNS and utun tunnel route changes as false TCP-down/DNS-up diagnoses
Parent: Apple Platform Publishing (Mac App Store) · Published reference · snapshot 2026-10-29
↓ Facts as markdownall context files
Source-anchored research for Fake-IP, split-DNS and utun tunnel route changes as false TCP-down/DNS-up diagnoses. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- A successful name lookup followed by a TCP timeout can result from route selection even when DNS returned an answer. Apple says the system routing table can supersede NetworkExtension included and excluded VPN routes. A macOS two-utun troubleshooting report describes a hostname resolving to 10.99.99.99 while a broad 10/8 route sent TCP and ICMP over the wrong utun; route -n get exposed the selected interface. (medium confidence) [source]
- The 2023 USENIX Security study demonstrates that VPN route exceptions can be manipulated to send traffic outside the protected tunnel. Its threat model concerns routing-based traffic leaks; it does not establish that routine macOS fake-IP or split-DNS TCP failures share that cause or measure how often they occur. (low confidence) [source]
Problems, failure modes and limitations
- A macOS dual-VPN report describes an internal hostname resolving to 10.99.99.99 while TCP and ICMP timed out: an aggregate 10.0.0.0/8 route through utun0 captured traffic intended for a second tunnel on utun15. The report recommends checking `route -n get <IP>` to see which route handles the resolved address before treating the symptom as DNS failure. (medium confidence) [source]
- For a VPN configured with includeAllNetworks set to true, Apple documents that the transition from disconnected to connecting leaves existing TCP connections open but drops their subsequent packets; when that VPN leaves connected state, the system drops network traffic. A TCP timeout during this tunnel transition can therefore occur without a DNS lookup failure. (high confidence) [source]
- A Versa support article reports the converse case after VPN disconnect: hostname resolution can fail while direct IP connectivity remains available when the VPN and underlay use the same DNS server IP and the system resolver remains pinned to a defunct utun path. DNS failures after a tunnel transition are therefore possible and should be checked directly. (low confidence) [source]
- Mihomo fake-IP mode can return synthetic addresses such as the documented 198.18.0.1/16 range. Its TUN documentation says macOS defaults to dns-mode disabled when unset and cannot automatically hijack DNS requests sent to the local network. A Clash Verge report shows the resulting resolver-path split: the system resolver returned router DNS results while Mihomo returned fake IPs; a direct request failed while a request forced to the fake IP succeeded. (medium confidence) (verified as of 2026-10-22) [source]
- A TCP-down/DNS-up symptom does not identify one root cause. Mihomo advises selecting the outbound interface explicitly when multiple interfaces are active. In an August 11, 2026 follow-up on the Clash Verge report, another commenter said enabling Mihomo sniffing restored connectivity without changing the TUN stack, strict-route setting, or TCP port 53 hijack. Check resolver results, the route and outbound interface, and the client's request logs before assigning the failure to DNS or a utun route. (medium confidence) (verified as of 2026-08-11) [source]
Facts and statements
- Apple configures packet-tunnel DNS resolver settings separately from IP included and excluded routes. `NEDNSSettings.matchDomains` selects DNS settings by hostname, while `NEIPv4Settings.includedRoutes` selects IPv4 destination traffic for the TUN interface. A live utun or route therefore does not establish which resolver answered a name, and a successful DNS answer does not establish which interface carries traffic to its IP. (high confidence) [source]
- Apple's NEDNSSettings.matchDomains selects which DNS queries use the tunnel resolver; nonmatching names use the system default resolver. Apple also documents that a VPN which becomes the network's default route uses its configured DNS servers as the default resolver and ignores matchDomains. A successful lookup alone therefore does not show which resolver produced the answer. (high confidence) [source]
- A Clash Verge Rev report updated on 2026-08-11 showed TUN routes through utun1024 while `scutil --dns` still selected the router on en0. System resolution returned real IPs, local Mihomo DNS returned 198.18.x.x Fake-IP addresses, and a forced request to a Fake-IP address received HTTP 302 while the ordinary request timed out. This case shows that TUN route presence alone did not prove the system resolver was using the intended Fake-IP path. (low confidence) (verified as of 2026-08-11) [source]
- Implementation inference from the split-DNS guide and the two-utun route report: inspect scutil --dns for resolver selection, then use route -n get <returned-IP> and test TCP to that same destination. A direct dig query to a named DNS server checks that server, while an application request tests the resolver and route path that the application actually uses. (medium confidence) [source]
Children
- macOS scoped DNS resolver selection (frontier)
- Network Extension route transitions and established TCP connections (frontier)
- Fake-IP DNS path verification (frontier)
Frontier under this node: Fake-IP DNS path verification, Network Extension route transitions and established TCP connections, macOS scoped DNS resolver selection