First of all - thanks for the tip on opening the port on the router. Open on the WAN side - yes?
I just tried it again this time w/o entering the address and yeah, it worked - assigned an IP. OK. I have no idea where the cockpit error was. Oh well.
Yeah. Well, actually I mean from everywhere, so in the input chain without additional filters. (The reason being that it’s not uncommon to have a zt connection from inside your own network. In this case ZT will discover that you’re actually on a common LAN and send traffic directly, but still encrypted/authenticated. Although this is not your current use case, actually this happens quite a lot, because many people use zt for access to the management network/vlan of their devices, because once it’s configured correctly, why not use it for access control even internally.)
It may be some bug. It’s quite common to see them discovered when someone is configuring something for the first time, because they do a lot of bad or unexpected thinks, and try so repeatedly.
FWIW, I do have a test script I’ve used before to enable the controller. I changed it to more closely match mikrotik instructions.
You should be able to cut-and-paste to /system/script, then run the system script. That will output the current ZT configuration things.
To setup a new fresh controller, you’d /system/script run <script_name> at CLI. Then use
[me@forum]> $ztcontroller make
Or to remove the controller setup, like in a test environment…
[me@forum]> $ztcontroller clean
To print the controller setup again, use
[me@forum]> $ztcontroller print
Not entirely the best script, but I recall there being some timing issue if you try to run the comment to close together. So maybe why folks see some oddities there.
:global ztcontroller do={
:if ($1 = "make") do={
:put "check zerotier instance 'zt1' is enabled"
/zerotier
:if ([:len [/zerotier/find]] != 1) do={:error "error - zerotier instance is not enabled"}
:local ztinstance [find]
:put "adding new controller..."
/zerotier/controller
:if ([:len [find]]>0) do={:error "error - already controller"}
:local ztcid [add name="ztc1" instance=$ztinstance ip-range=172.27.27.10-172.27.27.20 private=yes routes=172.27.27.0/24]
:local ztnetworkid [get $ztcid network]
:put "adding routeros interface for itself to controller..."
:delay 5s
/zerotier/interface
:local ztifaceid [add network=$ztnetworkid name="ztc-router" instance=$ztinstance]
:put "authorizing interface to access controller (please wait)"
:delay 5s
/zerotier/controller/member
set [find authorized=no] authorized=yes
}
:if ($1 = "clean") do={
/zerotier enable [find disabled]
/zerotier/interface remove [find name="ztc-router"]
/zerotier/controller remove [find]
/zerotier/controller/member remove [find]
}
:if ($1 = "print") do={
/zerotier
:put "\tINSTANCE"
print detail
:put "\tCONTROLLER"
controller/print detail
:put "\tLOCAL CONTROLLER MEMBERS"
controller/member/print detail
:put "\tINTERFACE TO ROUTER"
interface/print detail where name="ztc-router"
:put "\tINTERFACE IP ADDRESS"
/ip/address/print where interface="ztc-router"
:put "\tZEROTIER ROUTES"
/ip/route/print where dynamic gateway="ztc-router"
}
}
# to setup a new one, use "make" as argument & uncomment below
# $ztcontroller make
# to remove the controller, use "clean" in above instead of "make"
# always output when run
$ztcontroller print
And also I do recall oddities if you try “setup again”, without actually removing all the members or instance that used it. Or something like that. Why there is script to remove it too, and setup was automated…
Yup you can use that to update the routes later.
on [find]… All configuration has some .id (like with a * shown with “print show-ids”), and find will lookup those .id for something. The reason to do this is since someone may cut-and-paste something here and change the name from “zt1” or may already have a “zerotier1”, etc. Since you should have only one of these things, the [find] will get the one item whatever it’s named. But a plain [find] mean “all items” (and you can use it filter the items returned too – here I’m lazy since there is only one item)
Also, I dug up the script since I wasn’t sure what happened without the destination part (i.e. @172.27.10.2 syntax). What happen WITHOUT the @ part is RouterOS will add an interface route, so it will use the dynamically assigned IP. Thus ip-address was technically not needed when you do NOT use the @172… on the routes.
Personally, I think it’s better to set ip-address, so the router gets a fixed address & docs should discuss and show using ip-address - your setting up a NEW network and RouterOS is likely to be the default route so example should set it to .1. But, as technical point, their instructions as-is do work.
I think Mikrotik generally has a good reference documentation. I also think that it would actually mean increased sales for them if they provided a handbook style documentation as well, that would walk people through creating their first networks, vlans, etc. About 90% of the questions on this forum are about the same 10 topics, so discussing these at length, with examples (and yes, educating the reader in basic concepts regarding networking in the mean time) would be welcome by many.
EDIT:
For example I walked NA9D through some basic first steps with his router, such as: how to update software (yes, you have to update routerboot separately…), how to install packages, partition the device, create exports/backups, what the difference is, device-mode, to lock the rb5009 to a fixed cpu frequency… And there really is no piece documentation that would discuss this is an article, and I really think there should be one. These are basically steps that everyone has to go through before they can make effective use of their deivces.
I completely agree, especially regarding the steps to establish a good baseline. All major players like as Cisco, Juniper, and others, provide clear guidelines for the initial setup. I mean, how hard can it be? 
Regarding the handbook (I assume you’re referring to a user guide), it’s a great idea. It would also be beneficial if MT adopted the “Specification by Example” principle to ensure relevant examples are included in the online documentation. IMO, MikroTik should take a cue from Microsoft by allowing users to comment on documentation, which has significantly improved over time thanks to ongoing feedback.
As for cryptic and inconsistent explanations, I wasn’t referring to the BNF notation itself but rather to the text in Property/Description, specifically: “IP@GW” → Route ::= “Dst[@Gw]” which also lacks further clarification beyond “Push routes in the following format:” A few examples in the “Description,” similar to “ip6-range,” would have been sufficient to clarify the syntax.
Okay I had to read the docs to understand the use of the word controller. It would seem one can ‘bypas’ the zerotier site for setup and do it mostly on the mikrotik device.
Does this mean one is still using zerotier servers? How is information protected/encrypted using the controller?
Do you need a public IP address to run the controller.
Is this now the best way to provide any servers to external users ( no port exposure )
The ZT servers are still in use. The docs mention this:
A common misunderstanding is to conflate network controllers with root servers (planet and moons). Root servers are connection facilitators that operate at the VL1 level. Network controllers are configuration managers and certificate authorities that belong to the VL2 level. Generally, root servers don’t join or control virtual networks and network controllers are not root servers, though it is possible to have a node do both.
The ZT site is easy to use but for more control and customization, using the controller in the Mikrotik router is way better for multiple reasons…
1000% agree on overall need for “non-reference manual” presentation in docs, whether “user guide”/“by examples”/KBs, whatever… just there is a void between the “per command” view today and how to setup & use the router.
On ZT controller docs…
@anav, works same, so no public IP should be “required”.
The big difference between WG config is that instead of the various keys and network needing to match like in WG… With ZeroTier (including your own controller) all the “client”/peers needs to know is the ONE /zerotier/controller’s network= value. Unlike WG, authorization happens via RouterOS CLI — once the client tries to connect — you use /zerotier/controller/member commands above/docs to set “authorized=yes” on the “member” (of controller’s managed network). There are really only two numbers, address of peer & [controller] network id. The client’s address is provided when client tried to connect to a network, so client “zt-address” gets populated automatically by RouterOS, so you likely don’t need to care as much about that one.
Still the docs should mention that you can “pre-authorize” a peer to use the Mikrotik controller, if the user provides their client’s network address shown the ZeroTier client app. On Mac, if you select the “My Address” from the taskbar menu for ZeroTeirOne client, it will copy to clipboard. Then to use the client’s address to create a peer - before it connects, so it be authorized when it does, you can use the following:
:global clientztaddress "1fcfake1b8"
/zerotier/controller/member/add zt-address=$clientztaddress authorized=yes name=mymaczerotier disabled=no network=[../find disabled=no]
:put "In ZeroTier client, use 'Join' with network of: $[[/zerotier/controller/get [/zerotier/controller/find disabled=no] network]]"
In ZeroTier client, use ‘Join’ with network of: 847fake01fakecad
And the on Mac (or PC), to connect to that network, you need the “network id” for it. That in /zerotier/controller/print, but you can use above :put to display.
The other detail docs could mention is the name to use in the /zerotier/controller’s name= is what is displayed to in all client apps as the “friendly name” of the network.
And also, that controller will automatically assign IP address to peers within the ip-range= (and on any “member”/peer you can set an ip-address= to make a particular peer act like “static DHCP”). You kinda have to infer that a bit too much from list of attributes.
Control, yes. But I don’t know about more customization. i.e. There are flow rules on their controller. And the CLI does take some time to get used if you normally use winbox (aka @anav) - since the controller does not have webfig/winbox UI.
Just highlight, once again, an grip of mine is the Mikrotik’s ZT client does not support low-bandwidth, bonding, etc. as a “full” ZT client on PC/Mac does. And these restrictions still come in when using the controller, as traffic will go via the interface, not controller.
@NA9D - Unfortunately, you’re still a bit limited when it comes to running fully autonomous operations since ROS doesn’t let you configure root servers.
But with your own ZeroTier controller and ZeroUI, you not only get a slick web interface, but you also have full control over network rules, authentication, API access, and automation without restrictions. And you get better privacy and security too if that’s important to you.
Thanks AMMO, so controller is limited to CLI, is there a sense it will migrate to Winbox eventually. Will stick to non-self-controller option especially since the benefit is tied to using a third party git program which also has to be loaded onto docker??
Yeah, unfortunately. Guess we can always hope that MT fixes this someday.
Way too complex, so I don’t think so. But you can add your own web-based manager: ZeroUI.
Well, I’m actually surprised it’s not in the UI.
AFAIK, winbox/webfig UI is, mostly, automatic from the schema. And the current implementation of the controller only let you set only half dozen attributes & all are pretty “regular” from RouterOS schema. Perhaps other than our BNF friend routes=, but even with that winbox should know it’s array type and do multiple dropdowns with strings.
I do suspect the CLI-only-ness of the controller substantially limits its usage on RouterOS. That, and the applications of /zerotier/controller are not well described in docs (i.e. using ZeroTier “roots” for hole-punching, but you can mange the users on RouterOS (instead of at my.zerotier.com)… so its actually becomes kinda like BTH)
And, that also why a public IP shouldn’t be required when using /zerotier/controller to manager your own peers as asked by @anav . Although, of course, it be more reliable if you did have public IP (and ZT port explicitly opened to WAN).
The most practical application I can think of is my intention to host an NAS for images/video, and have it accessible by globally located family members etc.
Zerotier may be the best way to allow users to access, load, organize etc… my only concern is inadvertent deletion of files…
For that the normal ZT method be fine IMO. The client setup is trivial, you give your family member they install ZeroTierOne, click “Join Network”, and use a “Network ID” that you’ve given them. The client actually does not care if you’re using your own controller, or ZeroTier’s cloud one - it still be some globally unique network ID.
I guess we’re past Christmas… but buying your familar members a @anav-configured hAPaxLite to put on their remote LAN network side would allow you test the variety of VPNs you’ve explored over the years for this use case . You’d start with WG I’d imagine on these gifted hAPaxLite connected to your (old?) Tile router as the family “hub” & suspect you can add disks to your Tile and the ROSE package to do a NAS… Once you had WG on it, you can always add other VPNs to your ginny pig family members.
@anav - If I were you, I’d ditch the self-hosted controller and just use the cloud-based one (my.zerotier.com). Regarding your files, just: “# chmod +r *”. Fixed!
Larsa, are you trying to talk sexy at me “# chmod +r *”. ??
Sounds like, if was to guess, some linux NAS command to ensure read only LOL.
Ammo, sounds like too much recent smoke inhalation has impaired your judgment of what I am able to accomplish ( or my budget ).
I am starting a go fund me ( Low Canadian Dollar Fund ) to help defray the increasing cost of MT products.
Perhaps if we joined the EU… Nahhh, then we would have to help pay Spain and Greek Debt )
Haha, Anav, I see you’re out here securing your files and your finances at the same time! 
Maybe if we tweak that command a bit:
# chmod +Money
Boom! Instant economic growth! 
As for joining the EU… yeah, I think Canada prefers its maple syrup debts over Mediterranean siestas. But hey, if your GoFundMe takes off, maybe you can single-handedly peg the CAD to the Euro! 
And btw, Greece’s economy is actually doing better than ever: https://observer.com/2024/11/germanys-economic-decline-vs-greeces-surprising-comeback/
My question is how that work with frequency bands… Currently, Canada largely the FCC rules. For Wi-Fi, that likely better. For 5G/LTE with Mikrotik, you may be better off with EU rules… That lovely hAPaxLite-LTE6 is quite affordable but worthless in Canada (and US).