Yum update on Centos 7 killed zerotier

I have a centos 7 install that was working for a long time. Firewalld is diabled and I’m using iptables.
I did a yum update on the install and it left me with a no longer working zerotier.
Zerotier-one is running, and the node shows as “up” in myzerotier, yet it is unreachable from other nodes.
Also, on the host the cli is dead.

zerotier-cli peers
Error connecting to the ZeroTier service:
Please check that the service is running and that TCP port 9993 can be contacted via

I verified that firewalld is off. I check the logs for errors…
Mar 17 16:36:50 xxx yum[3864]: Updated: zerotier-one-1.6.4-1.el7.x86_64
Mar 17 16:57:48 xxx kernel: warning: zerotier-one' uses 32-bit capabilities (legacy support in use) Mar 17 18:13:02 xxx kernel: warning: zerotier-one’ uses 32-bit capabilities (legacy support in use)

Any ideas?

Can anyone explain this? I can’t run zerotier-cli yet the node shows “online” and zerotier itself is partially funcitonal (I can ping another remote node)

[root@xxx ~]# zerotier-cli peers
Error connecting to the ZeroTier service:
Please check that the service is running and that TCP port 9993 can be contacted via
[root@xxx ~]# ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=60 time=150 ms
64 bytes from icmp_seq=2 ttl=60 time=121 ms
64 bytes from icmp_seq=3 ttl=60 time=115 ms
64 bytes from icmp_seq=10 ttl=60 time=120 ms
64 bytes from icmp_seq=12 ttl=60 time=116 ms
64 bytes from icmp_seq=13 ttl=60 time=114 ms
64 bytes from icmp_seq=17 ttl=60 time=118 ms
64 bytes from icmp_seq=19 ttl=60 time=215 ms
64 bytes from icmp_seq=21 ttl=60 time=118 ms

I’ve tried re-installing, rebooting, etc. but it didn’t help. Are there interoperability problems?
Everything was working great until the yum update of Centos 7 and Zerotier.

All the other nodes not upgraded… some on 1.4 some on 1.2 are still working fine.
Should I attempt to revert to 1.4.6?

One other point to share…
This system has multiple routes to the Internet…

default via dev eno1 proto dhcp metric 100
default via dev eno2 proto dhcp metric 101
default via dev eno3 proto dhcp metric 102
default via dev eno4 proto dhcp metric 103

Maybe 1.6.4 is choking on that?

In a nutshell, what I’ve discovered is that newer versions of iptables appear to be interfering and blocking things by default which prevent zerotier from working correctly. My working Centos 7 config was last updated about a year ago. An update last week without any changes to iptables rules broke zerotier.
My zerotier usage is heavily dependent on other iptables routing rules but right now, zerotier is only working if I stop iptables. I’m working on the configuration to fix it. My iptables config. was intended to be heavily permissable by default because the system is on an isolated private LAN. It looks like I’m going to have to be very explicit now with permissions for zerotier.

I thought zerotier was “working” with iptables off, but in fact I still see packet loss of greater than 50% between zt nodes. I’m unable to open an ssh connection through zt. Also, I can ping a zt node with a public IP address and have greater than 50% packet loss, yet if I ping the node’s public IP I have 0% packet loss. How is this even possible?

I was able to use yum rollback to undo almost all the updates. After a reboot everything is working again.
If you are using centos 7 with zerotier, be very very careful!!!
Also, I don’t know if this means that zerotier isn’t working on a fresh install of centos 7. It may well not be.

Also, I find the silence here deafening. Can I be the only person to have encountered this problem?

I started a thread last November about a problem I had with a different zerotier implementation. The thread is closed now, but it turns out it was the same underlying problem. I hadn’t personally done the yum update on Centos 7 so I didn’t connect the dots at the time. I went back today and did a yum history rollback. Presto my zerotier full tunnel with IPv6 starts working again. It appears to have broken sometime in 7.8.

I hope this information can help others… it doesn’t seem possible that I’m the only person to run into this. These servers are generic Centos 7 installs.