Skip to content

Firewall Rules

Jump to bottom
Stefano Bertelli edited this page Jun 26, 2026 · 3 revisions

Firewall Rules

The Firewall Rules page (/admin/rules) manages network policies and per-user firewall rules enforced via nftables. (The sidebar entry is labelled Firewall Rules.)

Firewall Rules

Network Policies

Global toggles that control broad network behavior:

  • Allow peer-to-peer communication - When enabled, VPN clients can communicate directly with each other through the WireGuard tunnel
  • Allow local network to reach peers - When enabled, devices on the server's local network can reach VPN clients. Important: your LAN router also needs a static route for the WireGuard subnet — see LAN-to-Peer Routing for setup instructions.

These policies are applied immediately when toggled.

Per-User Rules

Fine-grained firewall rules that control what traffic VPN clients can send. Rules can be scoped globally (all users) or to a specific user, and are compiled into per-user nftables chains.

Rule Table

Column Description
Priority Evaluation order within the chain (lower runs first)
Action accept or drop
Destination Target IP/CIDR (e.g., 10.0.0.0/8, 0.0.0.0/0)
Protocol tcp, udp, or any
Port(s) Specific port or range (e.g., 80, 443, 8000-9000), or any
User The user this rule applies to, or Global for all users

Rule Priority & Ordering

nftables evaluates a chain top to bottom and stops at the first match, so the order of rules matters. Each rule has a priority — a lower number is evaluated first (closer to the top of the chain).

This is what makes "allow-list" setups possible. The canonical pattern for restricting a user to a specific set of destinations is:

  1. One accept rule per allowed CIDR (lower priority numbers)
  2. A single drop rule for 0.0.0.0/0 last (highest priority number)

Because the catch-all drop sits at the bottom, the accept rules above it are matched first; anything not explicitly allowed falls through to the drop.

Reordering: when you filter the table to a single user (see below), the rules render as a drag-and-drop list. Drag a row to change its position — priorities are renumbered and the user's nftables chain is rebuilt automatically. New rules are appended to the end of the chain by default; drag them into place or set the priority directly from the edit dialog.

Ordering is deterministic: the per-user chain is always (re)built in ascending priority order, including on startup reconciliation, so a catch-all drop can never accidentally end up ahead of your accept rules.

Filtering by User

As the number of users grows, reviewing one user's rules at a time becomes essential. The Filter by user selector at the top of the Per-User Rules card is searchable:

  • Choose All users to see every rule (read-only table, sortable by column).
  • Choose a specific user to see only that user's rules, rendered as the drag-and-drop ordering list described above.
  • With a user selected, clicking Add Rule pre-fills the Applies to field with that user.

Creating a Rule

Click Add Rule to open the creation dialog.

Create Rule Dialog

  • Destination (required) - Target IP address or CIDR range
  • Action - accept to allow traffic, drop to block it
  • Protocol - tcp, udp, or any
  • Port Range - Port number or range (leave empty for all ports)
  • Applies to - Scope to a specific user, or leave as Global (pre-filled from the active user filter)

Rules are applied to the nftables ruleset immediately upon creation. Editing a rule lets you change its action, destination, protocol, ports, priority, and scope.

Troubleshooting

The bottom section provides a button to view the current nftables ruleset for debugging. This shows the raw nftables rules as applied on the server, useful for verifying that rule order and firewall rules are correctly translated.

Clone this wiki locally