zerotier
Excessive data usage when idling - even in lowBandwithMode and disconnected from all networks (MacOS)
Problem
This has been reported multiple times but not been taken seriously enough and people moving to different VPN solutions:
- https://github.com/zerotier/ZeroTierOne/issues/694 - not actually completed, just closed
- https://discuss.zerotier.com/t/zerotier-huge-data-consumption/9436 - never addressed
- https://github.com/zerotier/ZeroTierOne/issues/1357 - not actually completed, just closed
Despite lowBandwithMode, the client is extremely chatty - sending and receiving substantial amount of data every 5s, even if not connected to any networks.
Service running, networks disconnected:
Service shut down:
local config:
zerotier-cli info -j | grep low
"allowTcpFallbackRelay": true,
"lowBandwidthMode": true,
Recommended solution(s)
- Add option to quiet ZeroTier - when UI is quit, shut down the service as well, not just the GUI
- When client disconnects all networks, also stop the service
- Reduce (like waaaaaay reduce) frequency of packets - it's impossible that every 5s we need to send packets
- Take lowBandwidthMode mode very seriously
It consumes about 3 Mb/s on my Windows 11 system without any connected networks
@adam-ah what version of ZeroTier were you running? There was an issue in 1.14.1 where the low bandwidth mode setting was being ignored. That's been resolved in 1.14.2
@Felix14-v2 Can you give us more details about your environment? It makes no sense for ZT to be using that much bandwidth without being connected to a network. That screenshot looks like there's a network with an active transfer happening..
Normal ambient data usage without being connected to a network should be less than 1KB/sec.
@glimberg Unsure what version sorry, I already uninstalled, and the filename / installer does not disclose version number. I downloaded the latest package from the official website on 1 Nov: SHA1 (ZeroTier One.pkg) = dca599f81b575dc1ce510b80bc2c31515849403b SHA256 (ZeroTier One.pkg) = 018e2368cf1f571606ad173339910470d3e253854b0bdb51b81b18d3c3105edd MD5 (ZeroTier One.pkg) = de5fc3a11d6f0bd1167006c277c98a18
Regardless of a bug with low bandwidth or not, I still stand by my original bug report and suggested solutions, as
- a not-connected client must not use any data and
- most certainly must not communicate every 5s, even if connected
It not only wakes up the radio on small and embedded devices leading to battery drain, it uses often expensive data for no reason (I hate comparing it to other products because ZeroTier is a fantastic idea and implementation, but WG, TailScale, ZeoTrust WARP all work as expected in this regard).
On another note, the "less than 1KB/sec" still adds up to 1KB * 3600 * 24 =~ 84MB/day. A disconnected client's acceptable use is approx. 0KB/day.
It makes no sense for ZT to be using that much bandwidth without being connected to a network. That screenshot looks like there's a network with an active transfer happening
The issue is that my only network has definitely been disconnected this time, that was the first thing I checked. And after having ho success, I had to completely disable the ZeroTier service to avoid such a huge network usage. Unfortunately I can't provide steps to reproduce the issue, because this bug happens randomly, but disabling networks definitely doesn't change anything:
https://github.com/user-attachments/assets/3ee21f63-fcad-4c14-afec-c57bef568713
All I can say is that this time I couldn't connect to my printing server via ZeroTier because of some weirdness with my connection (CONNECTION_TIMED_OUT), and this happened.
I'll try to update ZeroTier (just noticed that I hadn't updated it from 1.14.0 on this PC). Let me know if you need any more specific information, I just don't know what could be useful. And thanks for the answer!
UPD: still happens in 1.14.2
I noticed that actually ZeroTier stops destroying my bandwidth after some time if the network is disconnected, so this 1-5Mb/s data is just an overhead? As you can see from the demo above, the payload is about 0.1Mb/s, I don't believe this is an intended behavior.