Firewall
Watchgrid lets you create granular firewall rules that control east-west traffic within your WireGuard mesh. Rules can target a whole tenant, a site, or a single device — and are enforced as iptables entries on the server's FORWARD chain.
How It Works
WireGuard FORWARD chain
│
▼
WGISO-{iface} ← per-tenant chain
│
├── Gateway always allowed (both directions)
├── Admin devices always allowed
├── [Your firewall rules, ordered by priority]
│ allow/deny rules → ACCEPT or DROP
└── Default: DROP all remaining intra-tenant traffic
(when peer-to-peer is disabled on the tenant)
If Allow peer-to-peer is enabled on the tenant, all traffic is permitted and firewall rules are bypassed entirely. Disable it first to use granular rules.
Managing Rules
Go to System → Firewall to view and manage rules.
Scope Tabs
| Tab | Shows |
|---|---|
| All | Every rule across all scopes |
| Tenant | Rules applying to all devices in the tenant |
| Site | Rules applying to all devices in a site |
| Device | Rules applying to a single device |
Rule Table
Each rule shows:
- Scope — tenant / site / device with the target ID
- Action — Allow (green) or Deny (red)
- Protocol — tcp, udp, icmp, or any
- Source → Destination — IP, CIDR, or
any - Port — single port or range (e.g.
80,8000-9000), blank for any - Priority — lower number = evaluated first
- Enabled toggle — disable a rule without deleting it
- Delete — remove the rule permanently
Creating a Rule
Click + Add Rule and fill in:
| Field | Description |
|---|---|
| Scope | tenant, site, or device |
| Target | Select the specific tenant, site, or device |
| Direction | both — traffic flows in both directions (one rule covers src→dst and dst→src); outbound — src→dst only; inbound — dst→src only |
| Action | allow or deny |
| Protocol | any, tcp, udp, or icmp |
| Source | Source IP, CIDR, or any |
| Destination | Destination IP, CIDR, or any |
| Port | Port number or range — leave blank for any port |
| Priority | Lower = evaluated first (default: 100) |
| Description | Optional note |
Click Create Rule — the rule is applied to iptables immediately.
Priority and Evaluation Order
Rules are evaluated lowest priority number first. The first matching rule wins (ACCEPT or DROP). Rules after a match are not evaluated.
Example:
| Priority | Scope | Action | Protocol | Port | Effect |
|---|---|---|---|---|---|
| 10 | device | allow | tcp | 22 | Allow SSH to this device |
| 50 | site | deny | tcp | 22 | Block SSH to all other site devices |
| 100 | tenant | deny | any | — | Block all other tenant traffic |
Disabling vs Deleting
- Toggle off — rule stays in the database but is not applied to iptables. Toggle it back on at any time.
- Delete — removes the rule permanently.
Tenant Peer-to-Peer Setting
The tenant-level Allow peer-to-peer toggle (under Admin → Tenants → Firewall) acts as a master switch:
- On — all intra-tenant traffic is allowed regardless of firewall rules
- Off — devices are isolated by default; your firewall rules determine what is permitted
Admin devices (workstations) are always allowed to communicate with all devices in their tenant, regardless of rules.
Firewall and Kubernetes Cluster Agents
A K3s cluster agent is just another WireGuard peer in the mesh. It receives a tunnel IP (e.g. 100.64.1.11) and all traffic between it and other devices transits the server's WGISO chain — so firewall rules apply to it exactly like any other device.
| Traffic path | Controlled by firewall? |
|---|---|
| Watchgrid device → cluster tunnel IP | Yes |
| Cluster tunnel IP → Watchgrid device | Yes |
| Pod → pod inside the same cluster | No |
Pod-to-pod traffic inside a cluster uses the CNI network (e.g. 10.42.0.0/16 for K3s Flannel) and never traverses the WireGuard tunnel on the server. Those packets don't hit the WGISO chain, so iptables rules on the server have no effect on intra-cluster communication.
Common Patterns
Allow a specific device to reach a service port
Scope: device → my-sensor-pi
Action: allow
Protocol: tcp
Destination: 100.64.1.10/32 (IP of your MQTT broker)
Port: 1883
Priority: 10
Block inter-site traffic, allow intra-site
# Rule 1 — allow within site
Scope: site → london
Action: allow
Protocol: any
Priority: 10
# Rule 2 — deny cross-tenant at lower priority (handled by default DROP)
# No extra rule needed — the default DROP covers it