How do I add a line(s) to the firewall to allow access only to one ZT ip address?
and where does it go?
I can’t make head or tail of the instructions.
please?
Hello,
are you referring to the zerotier flow rules, or linux iptables, or something else? Which article are you looking at? thanks!
hi, nice to be here 
No articles. zerotier flow rules.
This is the bit about flow rules that appears below the issued ip address table for my network. I have spent ages trawling the web and zerotier and I can see it is brilliant, but I am not and I need worked examples, VERY simple ones. I can add complexity if I understand what works. So far all I achieve is to “break” all access. It was interesting to see the light concerning the use of NOT.
For example is it possible to limit all who access my NAS via zerotier to be unable to gain access to the LAN to which it is also connected? Synology if that is relevant.
I understand context is key in trying to offer help so please do not hesitate to enquire further of me.
I have wanted ZT for 20 years!
Anthony
The rules can be tricky. Thanks for reminding us.
Here’s a rule set that can allow access to “servers” but not other nodes.
https://zerotier.atlassian.net/wiki/spaces/SD/pages/222330881/Hub+and+Spoke
You might use that on one network with your users and have a second network for yourself.
haha! yes I was thinking exactly that, delete all my own devices and just leave the NAS on there - my worry was/is that this still leaves the “normal” LAN attached to the NAS and a bad actor could use the ZT NAS access to gain access to my local network.
I will have a look at your suggestion to see if I can not break it.
If I have only one suggestion it is please give me/us simple examples - one liners if you like, I do. Complex logic or even just sensible logic can be learned once the very basic syntax has been seen. As things stand I have been guessing over and over again.
I can only guess what a hub and a spoke might be.
Thanks very much for your reply
edit: I have now read the manual. I need to understand how tags and capabilities come in to being, they sound like variables, but I can’t see how they are defined. If they are pre defined where is this? For example is server a tag? Is it a capability? If either is that how the snippet you have offered me “knows”? Granted it is a bit late at night to be reading such matter.
All the best
Anthony
Some notes as I go along:
It looks like tags are defined by issuing the “tag” word followed by matters to associated with the name given and each one can have “sub tags” (?) of enum … and an “id” number, again a “sub tag” to the tag so named - and a “default” . So it’s a tag word that allows a name to be defined, then a set of parameters are associated with it being id, enum(s), default
Lightbulb:
`enum 100 sales # has no meaning to filter, but used in UI to offer a selection``Preformatted text`
All enum lines are offering menu choices to some user interface, they are irrelevant to the rules engine and .. can be ignored, deleted, not entered.. right?
ok so I am locked in here to a code box; don't know how to escapeOk, so had a response to inserting your suggested code, which is the remote server cannot “see” my server. Both are Synology NASs, and if we switch off flow control they work ok.
I’m not clear how the flow knows which “node” (is it?) is a server without being told (for example by reference to its ZT IP address or mac address or whatever).
Edit: I also have several computers (mac/PCs) doing remote backups to my NAS, so I just realised limiting to server to server won’t work for me. Ideally I would limit access by Mac address or IP address, but I guess that just serves to illustrate what I am trying (really hard) to do. I am ASSUMING that when a target ZT ip address is entered, then the source i.p. address “seen” by (presented to) the target device is also the ZT i.p. address and not dor example the WAN ip of the remote machine. Please confirm?
Thanks - even the smileys are complicated in here! (I’m laughing)
Anthony
Hello @serverside, I’ve had a hard time with flow rules too. It’s amazing feature that puts ZeroTier ahead of other solutions for me so I don’t know why it’s not getting too much love.
The biggest problem for me with the examples I found is that they all assume default allow policy, which is a huge NO-GO for me. I know it’s just a workaround to skip stateless firewall rules complexity, but is firewall really a place to cut corners?
Anyways, I came up with this template that I use:
## ------------------------------------------------------------------
## Custom tags START
## Custom tags STOP
## ------------------------------------------------------------------
## Allow only ZeroTier-assigned IP addresses.
drop
not chr ipauth
;
## Allow ARP.
accept
ethertype arp
;
## Allow ICMP.
accept
ipprotocol 1
;
## ------------------------------------------------------------------
## Custom rules START
## Custom rules STOP
## ------------------------------------------------------------------
## Default action
drop;
And then I fill up tags and rules that are appropriate for a given network.
For example, for RDP I would use this:
### RDP tags START
tag rdp_client
id 1031
enum 0 false
enum 1 true
default 0
;
tag rdp_server
id 1032
enum 0 false
enum 1 true
default 0
;
### RDP tags STOP
### RDP rules START
## Allow TCP traffic from RDP Client to RDP Server.
accept
ethertype ipv4
and ipprotocol tcp
and dport 3389
and tseq rdp_client 1
and treq rdp_server 1
;
## Allow return TCP traffic from RDP Server to RDP Client.
break
ethertype ipv4
and ipprotocol tcp
and chr tcp_syn
and not chr tcp_ack
and sport 3389
and tseq rdp_server 1
and treq rdp_client 1
;
accept
ethertype ipv4
and ipprotocol tcp
and sport 3389
and tseq rdp_server 1
and treq rdp_client 1
;
## Allow UDP traffic from RDP Client to RDP Server.
accept
ethertype ipv4
and ipprotocol udp
and dport 3389
and tseq rdp_client 1
and treq rdp_server 1
;
## Allow UDP traffic from RDP Server to RDP Client.
accept
ethertype ipv4
and ipprotocol udp
and sport 3389
and tseq rdp_server 1
and treq rdp_client 1
;
### RDP rules STOP
For SSH I would use this:
### SSH tags START
tag ssh_client
id 1001
enum 0 false
enum 1 true
default 0
;
tag ssh_server
id 1002
enum 0 false
enum 1 true
default 0
;
### SSH tags STOP
### SSH rules START
## Allow traffic from SSH Client to SSH Server.
accept
ethertype ipv4
and ipprotocol tcp
and dport 22
and tseq ssh_client 1
and treq ssh_server 1
;
## Allow return traffic from SSH Server to SSH Client.
break
ethertype ipv4
and ipprotocol tcp
and chr tcp_syn
and not chr tcp_ack
and sport 22
and tseq ssh_server 1
and treq ssh_client 1
;
accept
ethertype ipv4
and ipprotocol tcp
and sport 22
and tseq ssh_server 1
and treq ssh_client 1
;
### SSH rules STOP
You sould really create a test network and play around there. Don’t forget to tick tags for your nodes in ZT central. So far it works well for me on multiple networks.
1 Like
edit: tags, it’s not that+ plus sign under each i.p. address is it? I have found zero explanation for that as yet
Hi Michal,
Lovely to “meet” you and thanks for your sympathetic reply!
“Don’t forget to tick tags for your nodes in ZT central.”
That’s key info I have totally missed. Where do I tick tags in ZT central?
I will go look… but I have been looking for excatly that because it makes no sense how ZT can possibly know which node is tagged with which tag without some means of telling it.
I will be using your code there as a worked example to see if I can even begin to grasp this. It feels like there is some basic explanation missing, but I struggle to find the words for it. I used to “code” in a very hostile “language” but I need some place to start to understand it and ZT starts somewhere after Chapter 1 should be !
Regards
Anthony
p.s. this IS my test network, certain friends and family only.
First you paste flow rules and save changes. Then you scroll up to the members section and click the wrench icon next to the node’s address. You will see the tags section and that is where you assign values.
In my experience ZT is very smart and quick with propagating changes to the nodes. Sometimes it was not working as I expected so now I simply unauthorize+authorize node with changed tags and it always works.
1 Like
Thank you!
I just need to go and have a little cry in the corner: the tag system is so very simple when you know how to activate it.
So to do that: write the tag in to the flow control : THEN click the spanner against the related node(s) in the i.p. list and select it from the drop down tags list.
Anthony
there’s also a tags table below the flow rules after you create some tags.
yes there is! as if by magic I fell over it after creating my first tag, as i was wizzing up and down the page I spotted it - it seems that is the “tags matrix” referred to elsewhere, but that reference fails to mention it is invisible to novices, like the tags drop downs also are invisible to novices. I guess this was my baptism of fire and I am no longer a novice.
I am slowly moving on to capabilites, or would be if I weren’t struggling with “characteristics” that aren’t listed (meaning ipauth)
All part of the joy!
Anthony
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.