I’m trying to use Mikrotik as Zerotier controller. Everything works, together with EOIP.
Now i wanted to try routing over zerotier but i don’t realy know how to add managed routes, when controller is Mikrotik.
I created a VETH interface 172.15.0.5/24 with gateway 172.15.0.1 running OpenSpeedTest on port 3000.
Zerotier controller runs on the same device and its Zerotier network is 192.168.200.0/24, zerotier peer ip 192.168.200.9 and bridge ip 192.168.88.1
When i try to ping 172.15.0.5 from another Mikrotik device in the same Zerotier network with bridge ip 192.168.100.1 and Zerotier peer ip 192.168.200.10 that has added route in ip/routes 172.15.0.0/24 gw.:192.168.200.9 ping works. But if i try with device behind that Mikrotik device, adress is unreachable.
I also tried to add my phone on the same Zerotier network, phone got Zerotier peer ip 192.168.200.23 and can acess 192.168.88.1, but cannot acess 172.15.0.5:3000, that is on the same device.
Zerotier forrward and input rules are added in firewall.
To replicate the same ZeroTier “pushed” routes as my.zerotier.com controller… there is routes= on the /zerotier/controller. The controller is CLI only, and MT’s docs provide the format:
routes > Push routes in the following format:
Routes ::= Route[,Routes]
Route ::= Dst[@Gw]
So you should be able to set the routes that go to ZT members using something like this:
You can replace the [find] above with the interface name if you have more than one controller.
Since I’m not 100% why 192.168.88.1 works on phone actually… Perhaps you’re connected to Wi-Fi with that uses 192.168.88.0/24… that’s how a phone could get that route. I added the 192.168.88.0/24 route in above just to be sure. But maybe that really isn’t needed.
No, i’m 300 km away from this device, so no 88.1 here.
I did manage to add route as you wrote,
set routes="172.15.0.0/24@192.168.200.9"
. 192.168.200.9 is the IP of the Zerotier interface assigned by controler. What is making me problems now is, that as soon as i enter this, zerotier interface disapears from /ip adresses. Is this normal behaviour. If i then add IP’s manualy everything works, but it’s a bit strange why this happens?
How do you add another route, just copy everything and add more routes?
Edit:
I manage to make it work using this:
set routes="192.168.200.0/24,172.15.0.0/24@192.168.200.17,192.168.88.0/24@192.168.200.17"
(i started from begining after loosing route, so new ip adresses are in use)
What is interesting is, that 172.15.0.5:3000 works from all clients, but it’s impossible to ping this adress from Mikrotik that is zerotier client if i disable route i manualy added in /ip route.
EDIT2: After some cleanup and rebooting both devices, now everything works. Thank you for your help.
Just not sure about the auto-join using just the network id part of it.
FWIW, if you delete a /zerotier/controller, it does leave inactive /zerotier/controller/member’s… so that why my Mac just joined/authorized, I think (still it was a different/new controller).
It could be the default-route-distance= of ZeroTier instance (zt1) is 1, so depending on the distance= of any other 172.15.0.0/24 routers - check /ip/route/print… If you have a + in the status of any that mean the distance= of ZT matches a local route. Or do you have any routes for 172.15.0.0/24? Possible you need to allow-managed=yes on the local ZT interface that a member of the ZT controller, as that will inject the routes for routeros. You can also add a static route and skip the allowed=managed=yes.
Also, the interactions inside RouterOS firewall and zerotier are not well described in Mikrotik’s Packet Flow docs, and the local ZT interface via a local ZT controller all happens in the “local process” box in firewall.. Maybe you need to add the router’s ZT interface in LAN interface-list, but dunno.
I changed Veth adress to 172.16.0.0/24 range, since 172.15.0.0/24 isn’t private range. Then i had some packet loss when pinging. I did some cleanup in /ip routes and rebooted both devices and now everything works as it should.
I didn’t catch that, but yeah that ain’t private. So ZeroTier’s “allow-global=yes” would have been required … to enable a bad config … but why it didn’t initially work.
The most interesting thing in the end was, that it was still impossible to connect to the 192.16.0.5:3000 from apple mac, but it worked right away from android device connected to the same Wifi network. Not realy sure why, but at least it works now for the purpuse needed.