The whole security model starts at the network. One firewall everything routes through, three trust zones that can’t reach each other, and exactly one authenticated way in from outside. This page is the design — the addressing plan, the trust boundaries, and the actual firewall policy — not the parts list (that’s the lab overview). Home-LAN and public-IP specifics are deliberately left off; what’s here is the lab-internal design the posts already walk through, box by box.
Network Design
The lab's network from the design side — the addressing plan, the three trust zones, the firewall policy matrix, and the rules that don't change. Each row links to the post where it was built.
3
firewall-isolated trust zones — Trusted · IoT · Guest
1
inbound port — WireGuard UDP, everything else closed
RFC1918
all private ranges blocked outbound by one alias
stateful
first-match rules; permitted replies come back automatically
Addressing plan
One /24 core behind the firewall, three tagged VLANs on a single virtual trunk, and a separate range for VPN peers. Every segment is a routed interface on pfSense with its own gateway and DHCP scope.
| Segment | VLAN | Subnet | Gateway | Role |
|---|---|---|---|---|
| LAN core | — | 10.10.0.0/24 | 10.10.0.1 | pfSense LAN + the Debian automation VM; egress-only to the internet |
| Trusted | 10 | 10.10.10.0/24 | 10.10.10.1 | Full access — internet, other zones, and firewall admin |
| IoT | 20 | 10.10.20.0/24 | 10.10.20.1 | Internet only — blocked from every internal zone and admin |
| Guest | 30 | 10.10.30.0/24 | 10.10.30.1 | Internet only — blocked from everything internal |
| VPN clients | — | 10.20.20.0/24 | 10.20.20.1 | WireGuard peers, routed split-tunnel into the LAN core |
Home-LAN and public-IP addressing are deliberately kept off this page — an aggregated map is a better recon target than a detail buried in a post. Everything above is lab-internal only.
Trust zones
Three zones at deliberately different trust levels, plus the one authenticated way in from outside. What each zone may reach is the design.
Trusted
VLAN 10
Full trust
Reaches: Internet · every other zone · the firewall's admin UI
one rule: pass any → any
IoT
VLAN 20
Untrusted devices
Reaches: Internet only — no internal hosts, no firewall admin
DNS → block admin → block RFC1918 → allow internet
Guest
VLAN 30
Untrusted people
Reaches: Internet only — nothing internal, at all
same four-rule pattern as IoT
VPN clients
WireGuard
Authenticated remote
Reaches: Routed into the LAN core over a key-based tunnel
one inbound UDP port; split-tunnel Allowed IPs
Firewall policy matrix
Who may start a conversation with whom. Read a row as the source, a column as the destination. Because the firewall is stateful, an allowed flow's replies return automatically — so a green cell one way does not open the reverse.
| from ↓ / to → | Internet | Firewall admin | Trusted | IoT | Guest |
|---|---|---|---|---|---|
| Trusted · 10 | out | admin | — | reach | reach |
| IoT · 20 | out | blocked | blocked | — | blocked |
| Guest · 30 | out | blocked | blocked | blocked | — |
✓ allowed to initiate
✕ dropped — default-deny
· same segment / na
Remote WireGuard peers land on their own range and are routed split-tunnel into the LAN core — a separate, key-gated path, covered in the zones above rather than forced into this grid.
How a restricted zone is written
Order is the design. IoT and Guest share one four-rule pattern, evaluated top-down — the DNS allow has to sit above the blocks, because the resolver is the firewall, inside the private space those blocks would otherwise swallow.
- 1Allow DNS → the firewallthe resolver lives on the gateway itself
- 2Block → firewall adminno managing the firewall from an untrusted zone
- 3Block →
RFC1918aliasall private / internal space, in one object - 4Allow → internetwhatever's left is, by definition, external
Trusted (VLAN 10) skips all of it with a single pass any → any. That asymmetry — one permissive rule against four ordered ones — is the trust boundary, written out.
Design principles
The rules that don't change, whatever gets added next. Each links to the post where it earned its place.
Default-deny
Rules evaluate top-down, first match wins — and anything not explicitly allowed is dropped. The empty space at the bottom of the ruleset is the security.
Stateful returns
When the firewall permits a flow, its replies are allowed automatically — which is exactly why Trusted can open a connection to IoT while IoT can't start one back.
Egress control, not WAN type
The real property is that the automation VM reaches the internet but can't initiate into the home network — enforced by rules on the LAN interface, not by how the WAN is wired.
One RFC1918 alias
A single named object for all private space (10/8, 172.16/12, 192.168/16) turns 'block everything internal' into one self-documenting rule referenced by every restricted zone.
DNS above the block
The DNS allow rule sits above the blocks — the resolver is the firewall itself, inside the private space the blocks would otherwise swallow, so order it wrong and everything resolves nothing.
One key-based way in
Remote access is a single inbound UDP port for WireGuard — key-based, split-tunnel, terminating on the lab firewall. Overlapping subnets avoided by design; everything else inbound stays closed.