What’s happening?
· Other
How can we help?
· None of the above
Other options
· Other
Describe the issue
Roon Issue Report (Draft)
Subject: Critical Incompatibility: Roon Core binds to Cloudflare WARP virtual interface on macOS (M1/Silicon), causing Local Playback failure even in Split Tunnel mode.
System Configuration:
Hardware: MacBook Pro (M1 Silicon)
OS: macOS (Latest Version) running Roon Core (All-in-one App)
Network: Wi-Fi (en0), Cloudflare WARP installed (running in "Exclude IPs" Split Tunnel mode).
Issue: Local Playback (System Output/USB DAC) and Qobuz streaming fail (stuck at 0:00 or no response). However, Roon ARC works perfectly, indicating external download access is functional.
Problem Description: When Cloudflare WARP is active in "Split Tunnel (Exclude IPs)" mode, Roon Core fails to initialize audio playback. Despite adding extensive exclusions (LAN, Multicast, Qobuz, Akamai), RAATServer fails to communicate with the local audio device.
The issue is not a routing blocking issue (as ARC works), but an Interface Binding issue.
Troubleshooting Steps Taken: We have attempted the following standard troubleshooting steps with NO success:
Split Tunnel Configuration: Added 192.168.1.0/24, 127.0.0.0/8, 224.0.0.0/4, 239.255.255.250/32, akamaized.net, qobuz.com to WARP's exclude list.
Service Order: Manually set Wi-Fi service order above Cloudflare WARP in macOS Network settings.
Forced Routing: Used sudo route -n add -net 127.0.0.0/8 -interface lo0 to force localhost traffic.
IPv6: Set to Link-local only.
Process Reset: Killed and restarted RAATServer multiple times.
Critical Findings (The "Smoking Gun"): Upon analyzing the RAATServer_log.txt, we found that RAATServer is incorrectly binding to the WARP Virtual Interface instead of the physical Wi-Fi interface.
Log Evidence 1 - Binding to VPN Service: The log shows RAATServer connecting to warp-svc, which should not happen:
Plaintext
connectivity-check.warp-svc:61239
->0x351dd5f20ea8c45b
connectivity-check.warp-svc:53651
Log Evidence 2 - Binding to CGNAT Virtual IP: Instead of binding to the LAN IP (192.168.1.x), RAATServer binds to the WARP virtual IP (100.96.x.x):
Plaintext
100.96.0.21:49488
->0x5d57be85e7980d47
(Note: 100.96.0.21 is the assigned IP of the Cloudflare utun interface)
Log Evidence 3 - High Latency on Localhost: Communication to localhost shows abnormal latency (300ms+), indicating traffic is being routed through the VPN tunnel loop despite exclusions:
Plaintext
GET to http://127.0.0.1:9330/... returned after 307 ms
Root Cause Analysis: On macOS (specifically Apple Silicon with Network Extensions), Cloudflare WARP takes precedence at the system level. Roon Core / RAATServer does not seem to respect the macOS Service Order or Routing Table. It automatically binds to the WARP virtual interface upon startup.
Because RAATServer binds to the VPN interface (100.96.x.x), but the physical audio devices and multicast discovery packets are on the physical LAN (192.168.1.x), the audio stream packets are trapped inside the VPN tunnel, resulting in playback failure.
Workaround: The only working solution is setting WARP to "Include IPs" mode (with an empty list) or "DNS Only" mode, which prevents the virtual interface from intercepting all traffic.
Describe your network setup
cloudflare warp