Tag/flag access to ip

Hi all. Had a decent play around with the granular rules engine - works great.

What I’m trying to achieve is I have a bunch of clients, and a server subnet which is a managed route behind a ZT node, containing a bunch of minecraft servers.

I want to have a multi-select tag (flags, not enums) whereby I can select the servers that the clients have access to, then use the rules engine to enforce this.

Now the issue I’ve run into is I just can’t seem to work out a way to do this with flags. I’m aware I could do this with an individual tag for each server each with a yes/no enum - but it’s just not as tidy.

The below works great - until you permit acess to multiple servers. Then your binary tag changes value and it all breaks.


#define tag
tag access id 1
    flag 1 server_1
    flag 2 server_2
    flag 3 server_3

#permit access to server 1
  tseq access 2
  and ipdest

#permit access to server 2
  tseq access 4
  and ipdest

#permit access to server 3
  tseq access 8
  and ipdest

Ideally, I’d like to be able to do a bitwise AND on tseq with a given value (rather than the sender and receiver tags as tand does. Thus, if access AND 2 = 2, then the server 1 flag is set. If access AND 4 = 4 then the server 2 flag is set. This would still hold true if multiple flags are set. tsand & trand would be great thanks dev team :wink:

Feel free to say you’re doing it wrong… but only if you suggest something better!


I am interested in that as well ,
i would also be grateful for the one by one enum ruleset for access as i can not seem to make it work myself

How does return traffic make it back, in the example?

I haven’t thought it through, but sometimes using a capability fits better.
Maybe you can

break ipdest

cap server_1 id 1
   accept ipdest

all i can say is that it took me 2 weekends to figure out what the rules even are and how to set them,
ive read through everything i could find regarding rules , but couldnt understand it.
zt-travis reply didnt help as it wasnt a full ruleset.
I guess the only way to understand it is compare it to firewall policies which work in the exact same way:
first hit works, nothing after the first hit matters.

so for the struggling here is a ruleset that allows to manually set access to targets:

# The usual if not a valid traffic drop it rule
	not ethertype ipv4
	and not ethertype arp
	and not ethertype ipv6

cap to1 id 40
     accept ipdest;

cap to2 id 41
     accept ipdest;

cap admin id 444 accept;

drop not chr ipauth;

# allow arp and ping in the network.
accept ethertype arp or ipprotocol icmp4;
# allow dns
accept dport 53;
#allow returning traffic - without this its one sided communication.
accept chr tcp_ack;

You can do this, you just need to account for the addition of the flags. One issue is this won’t necessarily scale very well. With just 3 servers it’s not too bad, the more servers you add, the more permutations of the flags there will be. I’m not sure if the 10.10.10.x numbers were clients or servers, so I just used them for the server IPs below, they can be adjusted if needed. I also used a macro to make it a little cleaner.

tag servers id 1000
  flag 1 server1
  flag 2 server2
  flag 3 server3

macro serveraccess($flagvalue,$serverip)
      tseq servers $flagvalue and ipdest $serverip or
	  ipsrc $serverip and treq servers $flagvalue

### Server Values ###
# Server 1: 1
# Server 2: 2
# Server 3: 4

#Server1 Access
include serveraccess(1, #Server1 only
include serveraccess(3, #Server1 and Server2
include serveraccess(5, #Server1 and Server3
include serveraccess(7, #Server1, Server2, and Server3

#Server2 Access
include serveraccess(2, #Server2 only
include serveraccess(3, #Server1 and Server2
include serveraccess(6, #Server2 and Server3
include serveraccess(7, #Server1, Server2, and Server3

#Server3 Access
include serveraccess(4, #Server3 only
include serveraccess(5, #Server1 and Server3
include serveraccess(6, #Server2 and Server3
include serveraccess(7, #Server1, Server2, and Server3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.