Subnets

Bind a whole network segment to one profile instead of registering every device on it.

What this step does

Most networks aren’t one flat range. You might have a LAN and a Tailscale overlay, a guest VLAN, or an IoT segment sitting off on its own subnet — and you don’t want to add every laptop, phone and light bulb on each of them as a separate device just to give them a profile.

A subnet fixes that: bind a CIDR range to a profile once, and anything with a source IP inside that range inherits it — no matter how many hosts come and go.

Add a subnet

Both --cidrs and --profile are required.

warden subnet add tailscale --cidrs 100.64.0.0/10 --profile trusted
warden subnet add lan --cidrs 192.168.1.0/24 --profile trusted

The input forms --cidrs accepts

Written to disk as canonical CIDR either way, but the CLI and TUI take a friendlier superset at input time:

Non-contiguous wildcards (10.*.0.*), a range mixed with a wildcard, and a range that isn’t aligned to the prefix boundary it implies are all rejected. IPv6 has no friendly forms — write it as canonical CIDR.

Where a subnet sits in the chain

A subnet is level 4 of 5 in the resolver chain. A device’s own pinned profile, an active schedule targeting that device or its group, and the device’s group membership all win first if any of them match. The global default ([server].default_profile) is what a source falls back to only when no subnet matches either. See decision precedence for the full chain.

Overlapping subnets

When two subnets both cover a source IP, the longest matching prefix wins — a /24 always beats a /16 regardless of anything else. Only when two subnets tie at the same prefix length does priority decide (higher wins), and the subnet id breaks any remaining tie.

A device’s own profile — pinned directly, via an active schedule, or via a group — still beats any subnet match, as long as Warden identifies the device. Under the default [server] enforce_device_mac = true, a device pinned by ip with no mac (unless the ARP table shows one of its mac_aliases at its address), or one whose MAC in the ARP table is neither its mac nor one of its mac_aliases, loses those three levels, and the subnet applies to it. A MAC that another configured device owns identifies that device instead. See the MAC check.

Allow or deny a domain for one subnet

A subnet has no rules of its own. Rules live in Custom Lists mounted on a profile, so they reach every subnet, group and device that uses that profile. To confine a rule to one subnet, give the subnet a profile of its own first:

warden profile add iot --display-name "IoT"
warden subnet set iot-net profile iot
warden custom-list create iot-rules --display-name "IoT rules"
warden custom-list add iot-rules ads.example.com --deny
warden profile mount iot --custom-list iot-rules

The old warden subnet profile-allow and profile-deny commands are retired in 0.44.0 and refuse to write. See custom rules.

Check what a subnet actually matched

warden resolve 100.64.0.5

warden resolve <ip> prints the match level, the subnet id (if that’s what matched) and the effective profile against the config on disk — the fastest way to confirm a subnet is doing what you think before a real query hits it.

CLI reference

In the TUI

Section 3 · Network, leaf Subnets (g s).

See also

• Subnets (entity reference) — full schema, precedence chain, security notes
• Devices — profiles pinned to a single host, which always outrank a subnet
• Profiles — what a profile actually does with the domains a subnet routes to it
• Hierarchies — how subnets fit next to devices, groups and schedules