Network access control
Control which machines may reach which machines on the mesh, on which ports and protocols — default-deny, enforced at both ends, and audited.
Being on the mesh should not mean being able to reach everything on it. Network ACLs decide which machines may reach which, on what.
The shape of a rule
A rule names a source, a destination, and what may be reached:
| Field | Example |
|---|---|
| Source | A device, a tag, a user, or a group |
| Destination | A device, a tag, or an address range |
| Ports and protocols | tcp:22, tcp:443, udp:53, or all |
Tags are the useful part at any scale: tag machines prod, dev, laptop, and
write rules between tags rather than between machines.
Three modes — roll out through them, in order
| Mode | Behaviour |
|---|---|
| Off | No policy is applied |
| Warn | Decisions are evaluated and logged, nothing is blocked |
| Enforce | Decisions are applied |
Always go through Warn first
Switch an organization to Warn, then read what it reports. Every packet that would have been denied is recorded without being dropped, so you can see which of your rules are wrong before they cost anyone their access.
Network ACLs are feature-complete but have not yet been widely exercised in enforcing mode in the field. Warn mode is not ceremony here — it is the recommended path.
Enforced at both ends
A rule shapes what each machine is even told about — a peer you may not reach is not in your peer list — and is additionally enforced on arrival at the receiving machine.
That second half matters: it means a machine will not accept traffic it was never entitled to receive, even if the sender misbehaves. It also covers source and destination validity, so a peer cannot claim an address it does not own or address something outside what it advertises.
Fail-closed
An unreadable policy is a denial, not a grant
If the policy cannot be read, the answer is no. That sounds obvious and the opposite is a genuinely easy mistake to make: an implementation that treats “I could not load the rules” as “no rules apply” grants everything at exactly the moment something is wrong.
No policy versus an empty policy
These are different, and the distinction is kept
No policy compiled falls back to the coarse organization-wide scope. A policy that permits nothing denies.
Collapsing them — treating an empty list as “unset” — turns a deliberate denial into a grant. The same distinction shows up in several places in this product, and it has been got wrong at least once in each.
Relays are covered too
The rules gate relay use as well as direct connections, so a machine cannot reach a peer it is not entitled to by taking a longer path to it.
Auditing
Every decision is recorded. In warn mode the log is the whole point — read it before enforcing.
A worked example
A small organization with laptops, a build server and a production database:
- Tag machines:
laptop,build,prod. - Allow
laptop → buildon the ports developers actually use. - Allow
build → prodon the database port only. - Allow nothing from
laptop → prod. If someone needs the production database, they go through the build host, and that hop is visible. - Switch to Warn, work for a week, read the log.
- Switch to Enforce.
Step 5 is the one people skip, and it is the one that catches the rule nobody thought about.