[macOS 26.2] zerotier-one installs a global blackhole default route (default → 127.0.0.1/lo0) and demotes the real default to RTF_IFSCOPE → total internet loss

[0xP0]

Summary

On macOS 26.2 (Tahoe), starting the zerotier-one daemon installs a global blackhole IPv4 default route default → 127.0.0.1 (lo0) and simultaneously demotes the real default route default → <gateway> (en0) to interface-scoped (RTF_IFSCOPE). The kernel's global default therefore points at loopback, so all internet traffic is black-holed → total loss of connectivity. Directly-connected subnets (the ZeroTier managed /24 via feth, and the physical LAN via en0) stay reachable, which masks the cause at first.

Stopping the daemon (launchctl unload /Library/LaunchDaemons/com.zerotier.one.plist) immediately removes the default → 127.0.0.1 entry, restores the en0 default to GLOBAL, and connectivity returns.

This happens even though the network has allowDefault=0 and the controller advertises no default route — so it is not expected "Allow Default Route" behavior.

Environment

• ZeroTier One: 1.16.1 (macOS .app bundle, /Library/Application Support/ZeroTier/One/zerotier-one)
• OS: macOS 26.2, build 25C56, Darwin 25.2.0, arm64 (Apple Silicon)
• Datapath interface: feth (feth818 / feth5818 pair), MTU 2800
• Single joined network (PRIVATE), per-network local.conf:

  allowManaged=1
  allowGlobal=0
  allowDefault=0
  allowDNS=0
  

  • Assigned managed IP: 10.10.10.x/24
  • Routes advertised by the controller: only 10.10.10.0/24 (a LAN-style subnet). No 0.0.0.0/0 and no 0.0.0.0/1 + 128.0.0.0/1 split routes are advertised.

Evidence

Healthy (daemon stopped):

$ route -n get default
   gateway: 192.168.31.1
 interface: en0
     flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>

Broken (daemon running):

$ netstat -rn -f inet
Destination        Gateway            Flags               Netif Expire
default            127.0.0.1          UGScg                 lo0      <-- GLOBAL blackhole default
default            192.168.31.1       UGScIg                en0      <-- real gateway, now RTF_IFSCOPE
10.10.10/24        link#17            UC                feth818
...

$ route -n get default
   gateway: 127.0.0.1
 interface: lo0
     flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>

• ping to any internet host: 100% loss.
• ping 10.10.10.x (ZeroTier subnet via feth) and LAN hosts: OK.
• launchctl unload the daemon → the default → 127.0.0.1 entry disappears, en0 default flips back to GLOBAL, internet restored.

Reproduction

• 100% reproducible on every reboot. The LaunchDaemon has KeepAlive=true and starts early during boot, racing the primary interface's DHCP / default-route bring-up.
• Manually launchctl load-ing the daemon after the machine is fully up reproduces it only intermittently — consistent with a startup / route-ordering race in macOS scoped routing.

Ruling out other software

During reproduction no other route-managing software was active: Cloudflare WARP not running, Tailscale stopped, no Clash / sing-box / tun2socks / TUN-mode proxy (only a SOCKS/HTTP proxy that does not touch the routing table). The blackhole default → 127.0.0.1/lo0 appears strictly with the zerotier-one daemon and disappears the moment it stops.

Workarounds

• Start the daemon only after the network is fully up (avoid the boot race); or
• Set allowManaged=0 for the network — stops the breakage, but also drops the managed /24, so the ZeroTier subnet becomes unreachable.

Question

Is this a known regression with the feth datapath / route sync on macOS 26 (Tahoe)? Given allowDefault=0 and no controller-advertised default, installing a global default → 127.0.0.1/lo0 looks unintended. Happy to provide zerotier-cli listnetworks, route -n monitor, or unified-log traces on request.