I have an NVR directly connected to a MT3000 router that I wish to access remotely using Zerotier. Although I can access the router itself remotely, I cannot get to the NVR.
The virtual address for the router using Zerotier is 172.24.163.143 which resolves to 192.168.8.1 just fine. I have the following managed routes in Zerotier:
172.24.0.0/16
192.168.8.0/23 via 172.24.163.143
On the MT3000 under Zerotier App I have
LAN 192.168.8.0/24 via 172.24.163.143
WAN 192.168.68.0/22 via 172.24.163.143
and the router virtual IP is set correctly as 172.24.163.143
So I can enter either 172.24.163.143 or 192.168.8.1 and get to the router admin fine.
The NVR is at 192.168.8.200. I can't get any response from that.
What am I missing?
One odd thing - under the router's Client's section, 192.168.8.200 is listed as offline most of the time although it is connected. Every so often it briefly pops up to the online section for a second or two. This happens regardless of whether I am directly connected locally to the router via Wifi or if I am accessing it remotely with Zerotier. When on Wifi, the NVR interface is always accessible.
The topology is very simple - I'm just trying to get this to work so it's just a single router with an NVR connected via ethernet ports. The router is accessible via a simple Zerotier network over WAN, (or else is also acccessible via wiFi when the connecting device is local, but that is not my desired use case). Any device authorized to use the Zerotier network can connect to the router over WAN. So the base case topology is one Windows computer (or iPhone) connecting via Zerotier to one router which has a hard wire connection to an NVR. The router and the computer (or phone) are running ZeroTier. The NVR cannot.
More information - I connected another computer that is not running Zerotier to the network router via Wifi. I can't ping it either over ZeroTier. So the NVR is not at fault. It is a connection problem involving the router and Zerotier I believe. Turning Windows Firewall off makes no difference by the way.
I have come to believe that the problem is that the router is not responding properly to the request that comes from ZeroTier. If I ping an address within the range managed by my ZeroTier network, if no device is connected, ZeroTier responds to the ping that the device is unreachable. If a device is connected, it times out, which means that the request was sent successfully but no reply was received back to the ZeroTier address. This inclines me to believe that routing from the ZeroTier app running on the MT3000 is not functioning correctly by not using the managed routes I have set up for that ZeroTier network. Comments please!
I got the ZeroTier ID when I created a network through their web portal. If the router's ZeroTier is just a client, then I'm not following what the server is. The request comes from another ZeroTier client. It is trying to reach a device attached to the router that cannot run ZeroTier. If you mean that ZeroTier's hosting of the network is the server, then, yes, that's where the managed routes are added. But the router does not seem to be using that. Is there any way I can manually route the response from the router to the ZeroTier address for it?
Yes - see my original post above. Let me know if I need to add more routes to that. The device I'm trying to reach is within the range of the managed IPs so I don't understand why it doesn't work. The only address that works is the router itself, at 192.168.8.1
Also I'm wondering if any of this is a consequence of the version of ZeroTier running on the router. The router version is 1.10 I believe whereas the current version is 1.14. Is there a way to upgrade the version on the router?
ssh 192.168.8.1 responds "The authenticity of host '192.168.8.1 can't be established. ED25519 key fingerprint is SHA256:dvOnIG9QCO79YKdOjVEKPJJB0e6u9ymMy1HZCTkVNzg.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])
cat /etc/config/network responds 'cat' is not recognized. I am running under Windows 11.
ip route also is not recognized.