[Bug] macOS Tahoe 26: ZT peers unreachable when coexisting with NetworkExtension full-tunnel VPN (UniFi Teleport)

[Alanz0ka]

Summary

On macOS Tahoe 26, when ZeroTier is running normally and a second VPN
based on Apple's NetworkExtension framework (specifically UniFi Teleport,
which uses WireGuard via NEPacketTunnelProvider) is activated in
full-tunnel mode, all traffic to ZeroTier peers stops working —
even though every layer below the application appears healthy:

• zerotier-cli info reports ONLINE
• zerotier-cli peers shows healthy DIRECT and RELAY connections
• tcpdump confirms UDP/9993 traffic continues to flow bidirectionally
• ARP resolution succeeds on the feth interface
• route -n get <peer-ip> returns the correct ZT interface (feth2063)
• Outbound ICMP/TCP packets leave through the correct interface

But responses never reach the originating socket. The application sees
100% packet loss / connection timeout.

When the second VPN (Teleport) is disconnected, ZT peer connectivity
returns immediately with no other intervention.

Environment

• OS: macOS Tahoe 26 (latest official release)
• Hardware: MacBook Air (Apple Silicon)
• ZeroTier version: 1.16.1 (installed from official .pkg)
• ZT interface model: feth pair (feth2063 ↔ feth7063)
• Coexisting VPN: UniFi Teleport via WiFiman Desktop
  (WireGuard transport, full-tunnel with 0.0.0.0/1 + 128.0.0.0/1 routes)
• UniFi Controller: UCG Ultra running Network 10.3.58

Network topology

• Physical LAN (Wi-Fi): 172.16.0.0/24 (en0, default gateway 172.16.0.1)
• ZeroTier network "facedoor": 192.168.196.0/24 (feth2063, my IP .254)
• Teleport tunnel subnet: 192.168.2.0/24 (utun6, my IP .2.3)
• Remote LAN behind UniFi (via Teleport): 192.168.12.0/23

No subnet overlap between any of the three.

The peer I'm testing against (192.168.196.119) is another macOS device
running ZT, reachable only through the ZT mesh (RELAY path, ~280ms latency).

Steps to reproduce

1. Connect to ZeroTier network. Confirm peer is reachable:
   ping 192.168.196.119 → succeeds (~280ms RTT).
2. Open WiFiman Desktop and connect to Teleport.
3. Re-test: ping 192.168.196.119 → 100% timeout.
4. Disconnect Teleport.
5. Re-test: ping succeeds again.

Diagnostic data collected

zerotier-cli info (with both VPNs active)

200 info 374b36360a 1.16.1 ONLINE

zerotier-cli listnetworks

200 listnetworks 83048a0632f2ec2d facedoor 2e:db:b9:04:30:80 OK PRIVATE feth2063 192.168.196.254/24

Routing table (netstat -rn -f inet, relevant lines, with Teleport active)

0/1 utun6 UScg utun6
default 172.16.0.1 UGScg en0
128.0/1 utun6 USc utun6
192.168.196 link#15 UCSc feth2063 !
192.168.2.3 192.168.2.3 UH utun6

Note the ! (REJECT) flag on the ZT route. It appears immediately when
the route is auto-installed and persists even after manual route delete

• route add to recreate it. The flag is present regardless of whether
  the interface metric is 5000 (default for feth) or manually set to 0.

route -n get 192.168.196.119 (with Teleport active)

route to: 192.168.196.119
destination: 192.168.196.119
interface: feth2063
flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF>

So routing decision is correct — kernel chooses feth2063.

arp -an | grep feth (with Teleport active)

? (192.168.196.119) at 2e:f1:68:c0:57:3b on feth2063 ifscope [ethernet]
? (192.168.196.254) at 2e:db:b9:4:30:80 on feth2063 ifscope permanent [ethernet]

ARP for the peer resolves correctly.

tcpdump -i any "udp port 9993" (with Teleport active)

Continuous bidirectional UDP/9993 traffic with planet/relay servers and
peers. ZT control plane is fully functional.

pfctl -s info

Status: Disabled

So this is NOT a packet filter issue.

Workarounds attempted (none worked)

1. Manually delete + re-add the ZT route → REJECT flag re-applies, ping still fails.
2. sudo ifconfig feth2063 metric 0 then re-add route → no change.
3. Set "interfacePrefixBlacklist": ["feth"] in local.conf → ZT goes
   OFFLINE because no alternative interface is available on macOS Tahoe.
4. Restart com.zerotier.one service → no effect.

Hypothesis

macOS Tahoe's NetworkExtension framework, when a full-tunnel
NEPacketTunnelProvider is active, appears to intercept return packets
destined to the originating socket and drop those that arrive on
non-NE-managed interfaces. The feth pair used by ZT is not registered
as a NetworkExtension interface, so return traffic via feth2063 is
silently discarded by the NE layer before reaching the kernel socket.

This would explain why:

• Outbound traffic works (socket → kernel → route lookup → feth2063 → ZT mesh)
• Inbound traffic fails (ZT mesh → feth2063 → kernel → NE filter drops)
• Control plane (UDP/9993 over en0) is unaffected (en0 is the system
  default interface, not under NE supervision)

Impact

This breaks any usage pattern where users need ZeroTier peer connectivity
simultaneously with another NE-based VPN — a very common scenario for
people using Teleport, Tailscale Funnel, corporate VPN clients
(Cisco AnyConnect, GlobalProtect, etc.) alongside ZT for personal mesh.

On Windows 11 with the same exact setup (same ZT network, same Teleport
invite), both VPNs coexist without any issue.

Possible directions

• Investigate whether ZT can register its feth interface (or a
  shadow utun) with NetworkExtension on macOS to participate in NE-aware
  routing.
• Document this incompatibility officially if no fix is feasible, so
  users know to avoid the combination.

I'm happy to provide additional diagnostic data, sysdiagnose, or test
patches. Reproducible 100% of the time on my setup.