Clients connecting regardless of "AUTH" setting at my.zerotier.com

TLDR: ZeroTier clients are connecting to each other regardless of setting on my.zerotier.com.

I’ve been using zerotier for a while now and it’s been great, but I’m concerned for security now that I can connect to clients I shouldn’t be able to reach!!!

I have zerotier installed on Ubuntu 22.04 desktop and it is not closing connections. Well, I suppose it’s the zerotier backend, as the involved hosts use windows and ubuntu. I’d posted about the same problem before, but it seemed to be solved by rebooting Ubuntu so I left it alone. Well, this morning I get up, sit down at my desktop, and soon discover that I can still reach all three windows hosts I have configured, even though NONE are enabled/checked on my.zerotier.com, and haven’t been since at least eight or ten hours ago.
This time I rebooted each windows machine AND the ubuntu desktop machine, as well as the router/gateway at each location, all the while my.zerotier says they are NOT enabled/checked/authorized and I CAN STILL RDP TO ALL THREE WINDOWS MACHINES via their zt ip addresses.
This is absolutely a massive security problem. Can somebody PLEASE look into this?

For clarity;
The four hosts involved are on separate networks at different locations in four cities across two states. Been four hours or so since I noticed this was happening, just checked again; still no devices enabled/checked on my.zerotier.com, still have connectivity to all three win hosts. Wasn’t really looking for a hurry-up to move to wireguard, but I can’t leave my family’s homeservers like this.

Poking aorund some more; from another ubuntu 22.04 machine which hasn’t been used to connect to these hosts in some months, I get the expected behavior. This caused me to zeroteir-cli listnetworks on the ubuntu desktop that I can still connect from. It’s disturbing, as it returns…

root@Blondie:/home/jason# zerotier-cli listnetworks
200 listnetworks
200 listnetworks -redacted- HomeNet -redacted- ACCESS_DENIED PRIVATE -redacted- 172.30.54.202/16
200 listnetworks -redacted- Butch -redacted- ACCESS_DENIED PRIVATE -redacted- 10.150.20.61/24
200 listnetworks -redacred- Robbie -redacted- ACCESS_DENIED PRIVATE -redacted- 10.150.30.60/24

There you have it. zerotier-cli listnetworks shows all of them as access denied, meaning I should have no route to connect to them. No route. So, “You can’t get there from here.” But I can. Something is wrong with either the zt client app on Ubuntu/Debian, or with the backend, or both.

Even an expertly mal-configured client shouldn’t be able to achieve this.

ZT Engineer here. We’ve received your email as well and are looking into this but in every previous case that a user has reported such behavior it has always been due to one of the following:

  • Connectivity taking an unexpected path along their physical network unrelated to ZeroTier

  • Malformed auth/de-auth requests (or not making it to central at all)

  • Devices taking time (by design) to fall out of the automatically-renewing auth window.

I’ve tried to replicate your proposed conditions and did not see what you are reporting. We’ll continue to investigate but by the description of your issue it doesn’t seem possible. The client can’t simply refuse to get off the network and nor can a client just keep talking to someone with an old cert.

Sending us the contents of zerotier-cli dump from two machines that you believe should not be able to talk would be most helpful. Please use our secure ticketing system to do that.

Even if this turns out not to be a ZeroTier issue we’re still happy to help you get to the bottom of it.

Best of luck.

Sent the dumps to Lennon yesterday. This morning it is still doing the same. Have posted to thread on atlassian (ZT-6160) further steps taken this morning. LEAVE and then JOIN seems to restore a network to expected behavior, so something meant to be ephemeral is being retained by ubuntu/ networkd/netplan, IDK???

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.