ZeroTier 6PLANE and RFC4193 addresses are auto-removed after added on zerotier-synology

[palonsoro]

• What you expect to be happening.

While using zerotier-synology, I expect ZeroTier 6PLANE and RFC4193 addresses to work the same way than with my other Linux machines.

• What is actually happening?

When zerotier container starts up, the addresses are added for a moment but then they disappear. Only the link-local fe80::/10 remains.

Workaround: I can only have the ZeroTier 6PLANE and RFC4193 addresses if I uncheck the corresponding checkboxes on ZeroTier Central and re-check them again. That forces the IPs to be re-added and they don't seem to disappear again (at least for a while).

IPv4 is not impacted.

• Any steps to reproduce the error.

Just have either ZeroTier 6PLANE and/or RFC4193 addresses enabled on a zerotier network. Then stop and start a zerotier-synology container.

• Any relevant console output or screenshots.

Nothing worth attaching here. It is only needed to compare the outputs of ip -6 a s right before starting and few seconds afterwards.

• What operating system and ZeroTier version. Please try the latest ZeroTier release.

Synology DSM 7.0.1-42218 Update ZeroTier 1.8.4 via zerotier-synology.

[rjmalagon]

Yes. I confirm this. Something is missing there because you can add manually the correspondent IP6 address to the tun interface with the native CLI tools, and it works. I suspect it is a docker issue. The NAS has IPV6 support enabled, the docker image config for IP6 is not enabled by default, the tun interface is directly exposed to the docker image, but the docker image itself somewhat fails to assign IP6 configs.

[palonsoro]

@rjmalagon sorry but you have missed 2 very important details here regarding docker:

• The Zerotier container runs in the host network. Running in the host network namespace means that the Zerotier container is not isolated in terms of networking, sees the same network interfaces than a regular process do and docker touches nothing in what regards the container networking just because there is nothing such a "container networking", it just uses the regular network stack of the host as if it wasn't a container.
• The Zerotier container is assigned CAP_NET_ADMIN and CAP_SYS_ADMIN, which basically gives them all the necessary privileges to perform its tasks.

Also remember that, as mentioned above, if I uncheck and re-check the checkboxes for ZeroTier 6PLANE and RFC4193 addresses, I can get them re-added without using the native tools, i.e. zerotier is perfectly able to add those addresses without a problem. It is just that something is causing them to be immediately deleted at startup and that effect doesn't trigger afterwards. But, as mentioned, the docker engine performs no network management on a host network container, so it cannot be that.

[joseph-henry]

I haven't yet confirmed this is the issue for IPv6 with the Docker container but I've noticed a new bug in synonetd that causes routes to be removed shortly after being added. In the DSM 6 package we get now get around this by checking the routes needed by ZT and periodically re-applying them. We might need to do something similar here.

[palonsoro]

I do recall having issues in the past with managed routes in DSM packages that match what you say, but at that time I did not have time for a proper investigation