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

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.