Closed aruznieto closed 10 months ago
Need to investigate. It appears that the issue may be related to the ZeroTier controller, possibly due to the 1.12 release. If the data is being written to the controller correctly from ZeroUI, then this could be the source of the problem.
Please report your ZeroTier controller version. If it's higher than 1.12, you might want to consider downgrading and trying the 1.10 release to see if that resolves the issue.
My version is 1.12.2 (zyclonite/zerotier:latest). Can I downgrade it without lossing anything?
Need to investigate. It appears that the issue may be related to the ZeroTier controller, possibly due to the 1.12 release. If the data is being written to the controller correctly from ZeroUI, then this could be the source of the problem.
Please report your ZeroTier controller version. If it's higher than 1.12, you might want to consider downgrading and trying the 1.10 release to see if that resolves the issue.
Does not work with 1.10
Hmm, may be it somehow related to https://github.com/dec0dOS/zero-ui/issues/164#issuecomment-1752727430
There is no bug here
It took me some times to understand how capabilities work : your rule should not end with drop;
have a look at my (working) flow rule :
# Allow only IPv4, IPv4 ARP, and IPv6 Ethernet frames.
#
drop
not ethertype ipv4
and not ethertype arp
and not ethertype ipv6
;
#
# drop non-ZeroTier issued and managed IP addresses.
#
drop
not chr ipauth
;
# Block TCP SYN,!ACK to prevent new non-whitelisted TCP connections from being initiated
# unless previously whitelisted or allowed by a capability.
break chr tcp_syn and not chr tcp_ack;
break ipprotocol 1;
# Capabilities
cap dns
id 10
accept ipprotocol udp;
accept ipprotocol tcp;
accept dport 53;
;
cap http
id 11
accept dport 80 or dport 443 and ipprotocol tcp;
;
cap ssh
id 12
accept dport 22 and ipprotocol tcp;
;
cap ping
id 13
accept ipprotocol 1;
;
cap zeroui
id 14
accept dport 4000 and ipprotocol tcp;
;
# Accept anything else. This is required since default is 'drop'.
accept;
as you'll see, my flow rule is greatly inspired from this article
But the last rule is like the "default" rule right? If I want to drop by default... If I set a cap that accept the packets, it should be work right?
No it is not, the default rule is drop
as written in the default flow rule, read the comments in the flow rule I posted, it says it all
Docs says drop can't be overriden by capabilities, you want to break
instead which can be overriden by a cap
Mmmm, thanks you!!
Bug Report
ZeroUI version:
v1.5.8 (latest)
Current behavior:
When I create an acceptance cap and then a drop, the packets drops.
Steps to reproduce:
Create a Flow Rule like I show before, assign it to one client and try ping to other device connected at the network