Access Control Lists

By default, no peer can reach another unless a rule allows it. ACLs are written between groups: place peers into groups, then write allow rules between them.

Groups

Every peer is always a member of Default, whatever else it belongs to. A setup key can drop a first-time enrollee straight into extra groups on top of that.

A fresh account is seeded with one rule — group:Default → group:Default, allow — so an out-of-box mesh is not cut off. Delete or tighten it to lock things down.

Deny by default

With zero rules, nothing talks, even within the same group. Access is something you grant, not something you remember to revoke. This applies to forwarded traffic too: a rule governs whether a peer may reach a subnet another peer advertises, so there is no separate route-visibility system to keep in sync.

Replies are allowed automatically

You do not need a return rule. Traffic a peer initiated is admitted back statefully — the same guarantee conntrack gives on Linux — while unsolicited inbound traffic is still matched against your rules.

An example

Put your web servers in group:web, your databases in group:db, and your admin laptops in group:admin. Then allow group:web → group:db on the database port, and group:admin → group:db for maintenance. Nothing else reaches the databases.

Enforcement

Rules are evaluated first-match-wins, in priority order, on every platform:

Linux, kernel TUN — an ordered BLINEX-ACL iptables chain
Windows — an in-process filter on every decrypted packet entering the OS. Windows Firewall cannot express “default deny plus a few allows”, because its block rules always beat allow rules regardless of order
Netstack peers (no /dev/net/tun) — the userspace forwarder applies the same check to everything it routes

Managing rules

Use the Access Control page in the dashboard, or the REST API:

curl -sk -X POST https://your-host:8080/api/v1/rules \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"web to db","src":"group:web","dst":"group:db","protocol":"tcp","port":5432,"action":"allow","enabled":true,"priority":100}'

Removing the last rule flushes the chain rather than leaving stale entries behind, so deleting a rule really does revoke the access it granted.