Zerotierone: Failing to assign IP to network interface

[ghost]

Ubuntu 18.04 LTS, fresh install from ISO.
Zero-Tier adapter initializes, but does not assign IP address
Output of ip address:

3: ztppiy6cts: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN group default qlen 1000

    link/ether 6e:d5:bb:11:74:0d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6cd5:bbff:fe11:740d/64 scope link
       valid_lft forever preferred_lft forever

Output of hostname -I: 104.251.214.59 -- this is the ens18 interface address)

No errors show in /var/log/syslog at boot. However, if I do service zerotier-one reload or systemctl reload zerotier-one I get the following

4: ztppiy6cts: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN group default qlen 1000

    link/ether 6e:d5:bb:11:74:0d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6cd5:bbff:fe11:740d/64 scope link
       valid_lft forever preferred_lft forever

and this line appears in /var/log/syslog

Jul 15 18:42:31 vhub networkd-dispatcher: WARNING:Unknown index 4 seen, reloading interface list

This node and four others were setup using the same script, and only this node is experiencing the issue. The nodes are at linode, vultr and at vpsdime (this node).
Information from uname -a from this node
Linux vhub.vnc.news 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
and from a couple of the working nodes
Linux lin1.vnc.news 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Linux vul1.vnc.news 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

All nodes are running client version 1.2.8

The ZeroTier web interface shows this node online along with the others, as seen in this screenshot.

Output of zerotier-cli info : 200 info 414e0dea77 1.2.8 ONLINE
Output of zerotier-cli listnetworks:

200 listnetworks <nwid> <name> <mac> <status> <type> <dev> <ZT assigned ips>
200 listnetworks e5cd7a9e1cf5946e vnc.news 6e:d5:bb:11:74:0d OK PRIVATE ztppiy6cts -

I've tried leaving and joining the network. I've tried uninstalling and reinstalling ZeroTier. Where do I turn from here?

[ghost]

Based on a question in the community forum: the tun driver is enabled:
Jul 15 19:05:00 vhub kernel: [ 1.564309] tun: Universal TUN/TAP device driver, 1.6

[glimberg]

You're running into an issue with the latest iproute2 utility. In the current releases, ZeroTier forks & calls /sbin/ip to set network interface settings. ZeroTier also uses setcap system calls to only give itself the permissions it requires and then drops to the zerotier-one user from root. This all worked fine and dandy until someone that works on iproute2 decided to not honor the setcap permissions on other processes when it's called.

There are 2 solutions:

• Modify the systemd script and add the -U command line option. This stops ZeroTier from dropping privileges and it will then run as root.
• Delete the zerotier-one user and group.

We have code in the edge branch that no longer depends on fork/exec calls to /sbin/ip, but it still needs more testing.

[ghost]

/lib/systemd/system/zerotier-one.service:

[Unit]
Description=ZeroTier One
After=network.target

[Service]
ExecStart=/usr/sbin/zerotier-one -U
Restart=always
KillMode=process

[Install]
WantedBy=multi-user.target

zerotier-one user and group removed. Node rebooted. No change in behavior from the original report.

[adamierymenko]

ZeroTier does this setuid/setgid stuff itself. If those users exist on the system it will assume them.

[ghost]

Just to be totally clear:

• I removed the zerotier-one user and group
• I edited the systemd file as indicated above
• I ran systemctl daemon-reload
• output of ip address is as shown in the original post
• I rebooted the machine
• output of ip address is as shown in the original post
• based on @adamierymenko post yesterday, I removed the -U from the systemd script and repeated the above steps. There is sill no change in output from ip address

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:18:9c:cf:92:46 brd ff:ff:ff:ff:ff:ff
    inet 104.251.xxx.xx/25 brd 104.251.XXX.XXX scope global dynamic ens18
       valid_lft 86306sec preferred_lft 86306sec
    inet6 fe80::218:9cff:fecf:9246/64 scope link
       valid_lft forever preferred_lft forever
3: ztppiy6cts: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN group default qlen 1000

    link/ether 6e:87:e6:73:b2:15 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6c87:e6ff:fe73:b215/64 scope link
       valid_lft forever preferred_lft forever

further, zerotier-cli status returns 200 info 13136f2c6f 1.2.8 ONLINE and the ZeroTier web page for this network shows the client number as ONLINE.

So we're still at the starting point. Since t his is a VPS, I'm close to deciding to just blow it out and start over from the ISO, to see if there's a difference the next time it comes up. I'll wait to do that for one more round of assistance with the node in this state.

[A-Helberg]

Hi All,

I had the same issue, but the node in question was used to forward traffic from a ZT network to a Local Network.

I had not set AllowManaged=0, so I'm guessing the routing got confused and it couldn't get it's IP.

Hope this helps someone.

[henrist]

I had a similar issue where the interface was left without any IP when setting up a CoreOS instance running latest ZeroTier One in Docker. I added a wrapper around ip and could see that zerotier-one indeed did set an IP, and that the interface actually had an IP for a short moment.

This led me to realizing that systemd-networkd was interfering with the interface setup. From https://www.freedesktop.org/software/systemd/man/systemd-networkd.html:

[...] it will flush existing network addresses and routes when bringing up the device

By making the interface unmanaged the problem was resolved. I added this to /etc/systemd/network/50-zerotier.conf:

[Match]
Name=zt*

[Link]
Unmanaged=yes

After restarting systemd-networkd and starting zerotier-one again, the link got an IP and working networking!

[bhamilton1co]

From what I have seen, the most common issue for failing to receive an IP address on a ZeroTier Network interface, is a simple TYPO in ZeroTier Central. Example: you change Managed IPs and/or IPv4 Auto-Assign pool, but you forget to update Managed Routes, or you do in fact update the Managed Route, but you make a typo, like typing in 10.0.0.0/24 instead of 10.10.10.0/24 etc, etc. Don't ask me how I know. SO, always triple check your ZeroTier Central settings first.

[gutleib]

Experiencing the same issue.
Fresh Debian install + Proxmox.
ONLINE, no ip, and a -1.-1.-1 version in zerotier central

[hossnys]

i'm facing the same problem now again as i authorized my host on the zerotier and it didn't take ip

ACCESS_DENIED PRIVATE ztuga6m63x -

[lancelon]

I've got the same issue as @gutleib. ONLINE, no IP and -1.-1.-1 version

[zhhuabj]

I've got the same issue as well

[zema1]

+1, same as above, no ip and -1,-1,-1 version

[DrewDogComputers]

Have no ip and -1,-1,-1 version, on windows 10 though.

[gustavosbarreto]

Same issue here

[jdrews]

ZT won't assign an IP to an interface if there's no (LAN) route for the IP you're trying to set. Can you double check that the IPs you're trying to set are in bounds of the subnet for (LAN) at ZT Central (my.zerotier.com).

[lancelon]

@jdrews yeah...that's not the issue. It's something to do with the Zerotier service. I still have the problem on one of my Windows machines that despite the service being set to automatic, it only works if I 'restart' the service. Great tool though! I'm not moaning!

[philipxyc]

I had the same problem, status shows online but version shows -1.-1.-1
Finally I find the root cause is the duplicate name on zerotier central. Please double check if the (short name) field is unique. Hope this helps!

[glimberg]

@philipxyc The name field is display metadata only and not used by the controller at all

[philipxyc]

@philipxyc The name field is display metadata only and not used by the controller at all

Sorry that I am not aware of the project structure. I've rename the my record back to the duplicate name, the network still function normally, so it seems that the error have nothing to do with duplicate names. But my problem was indeed solved right after I rename my record hours ago, probably it was due to other tricky problems. Anyway, thank you for developing this excellent tool!

[FAFDK]

Yesterday I was struggling with the same issue, but....today I saw that my self assigned IP was disappearing everytime I refreshed the page at the ZT CP, so I set it to auto assign, and boom, I got my IP and it's working, still show UNKNOWN group on Arch though. So for me, it was just to set it to auto on the IP. Version installed is: Zerotier-one 1.4.6-1

[ALTinners]

For those looking here in relation to the solution in https://github.com/zerotier/ZeroTierOne/issues/809#issuecomment-450458259

systemd-networkd will only pickup network configuration files ending in .network as per the documention in https://www.freedesktop.org/software/systemd/man/systemd.network.html

So - make that file /etc/systemd/network/50-zerotier.network