In preparation for DSM 7 upgrade I first want to be sure ZT in a docker container is working as expected.
The ZT NAS package works, in combination with network rules in ZT environment and my local router, almost flawless. For example on remote location I can still see my NAS in Mac Finder; other NAS services can be accessed via local IP addresses & ports, Apple time machine is working.
For the ZT container setup I used the following docker compose file:
version: ‘3’
Starting the container gives no error and after submitting the command line join command the new device is visible in ZT online portal. I can authorise the new device.
My issues:
The new device can’t be pinged from any other device. Not on the ZT IP address nor the local IP address
In the container logs keep appearing the following error: connect: Connection refused
All working items with the package are not working. No Nas in Mac Finder, etc etc
As for remote access to my NAS I can use a VPN connection.
I have done some more testing on my entire setup. At the moment I am testing from a remote site. I can access my NAS via VPN connection and Synology Quickconnect has been disabled.
As for my local network setup. My router is using a local DNS setting, which is the pi-hole container running on my NAS via macvlan network address. My router has a IPv4 route added for ZT network via Nas (local ip-address).
In addition to my ZT docker container I have setup a virtual DSM 7 with also a ZT docker container for testing purpose.
Before starting the DSM 6 docker container I make sure the network routing is in the ZT portal is setup correctly. Thus ZT local network via ZT ip-address for the container…
When the container is running I get the following errors in the container log:
connect: Operation timed out
connect: Connection refused
When I try to ping the ZT network from inside the container it can’t reach any devices. In the ZT portal it is mentioned connected but I can’t reach anything via a ping. On a command line on my NAS I can ping the ZT address of my container. From inside the container I am also able to ping other devies on my local network.
However when I access the command line of the Virtual DSM ZT Docker container I can ping other ZT devices. Thus this container is connected properly to the ZT network.
This looks like my local network (routing?) on my NAS gives issues as soon as the Docker container is started.
An other symptom I notice is, when I start a VPN connection.
When the ZT container is not running I can access my Nas and internet at the same time.
When the ZT container is running I can access my NAS but can’t access internet.
For me this looks like a local network issues, not a specific ZT docker container.
But what, where , how? I am confused.
That’s indeed a lot of confusing things going on.
A few more questions
Are you running in bridge mode?
If you’re not running in bridge mode, is the IP range of the ZT network separate from the range of the LAN?
If you run zerotier-cli info in the container, what is the status?
If you run zerotier-cli listpeers in the container, do all the peers have an IP adres? Do you see your virtual DSM listed as a peer?
If you uncheck the interface in the zerotier portal, does the internet connectivity resume?
Are you behind NAT?
For me the biggest clue is that your internet stops working as soon as zerotier is running. I’ve seen it in a case where the default gateway is also assigned in the portal. In case you are running in bridge, make sure not to assign the default gateway IP to any of the nodes.
I would switch of the virtual DSM off while you are testing too simplify the network setup.
You can also check what happens if you leave the network (does internet connectivity resume?) and if your rejoin…
Is your VPN range separate separate from your LAN and ZT range?
If you could share maybe share the network config (ranges, route entries) it would make it easier to check. With everything sensitive removed of course. (Maybe change IP ranges to something equivalent and leave out MACs or so).
Because you have a VM, a LAN, a VPN, a ZT network, a docker container,… there is a lot of room for tricky combinations which might not be obvious.
