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 127.0.0.1
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)
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 127.0.0.1.
[root@xxx ~]# ping 10.244.189.84
PING 10.244.189.84 (10.244.189.84) 56(84) bytes of data.
64 bytes from 10.244.189.84: icmp_seq=1 ttl=60 time=150 ms
64 bytes from 10.244.189.84: icmp_seq=2 ttl=60 time=121 ms
64 bytes from 10.244.189.84: icmp_seq=3 ttl=60 time=115 ms
64 bytes from 10.244.189.84: icmp_seq=10 ttl=60 time=120 ms
64 bytes from 10.244.189.84: icmp_seq=12 ttl=60 time=116 ms
64 bytes from 10.244.189.84: icmp_seq=13 ttl=60 time=114 ms
64 bytes from 10.244.189.84: icmp_seq=17 ttl=60 time=118 ms
64 bytes from 10.244.189.84: icmp_seq=19 ttl=60 time=215 ms
64 bytes from 10.244.189.84: 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.
One other point to share…
This system has multiple routes to the Internet…
default via 10.100.40.1 dev eno1 proto dhcp metric 100
default via 192.168.50.1 dev eno2 proto dhcp metric 101
default via 192.168.49.1 dev eno3 proto dhcp metric 102
default via 192.168.48.1 dev eno4 proto dhcp metric 103
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.
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.