Privacy is a Property, Not a Feature: an architecture of verifiable defaults at home

TL;DR

1. The problem

Most home networks trust the Internet Service Provider implicitly. The ISP sees every DNS query, every website visited, every device on the home. A typical consumer router offers no segmentation: a smart bulb has the same network access as a banking laptop.

This project asks: what if the default was the opposite?

• No traffic leaves the home unless it travels through an encrypted VPN tunnel.
• DNS queries never reach the ISP, even during failover events.
• Guest devices, IoT gear, and trusted laptops live on separate, firewalled networks.
• If the VPN fails, traffic is blocked, not leaked.

2. Architecture at a glance

Topology

A "router-on-a-stick" design: one firewall, one switch, all networks ride a single tagged link.

Hardware

Software stack

3. Privacy architecture (the core)

Threat model

• Adversary 1: the ISP, observing every byte that leaves the house.
• Adversary 2: a misconfigured device or app trying to bypass the VPN.
• Adversary 3: a transient VPN failure that "fails open" and leaks plaintext traffic.
• Out of scope: nation-state actors, supply-chain attacks on the firewall itself, physical theft.

Defense layers

Verification

Tested via ipleak.net and mullvad.net/check:

4. Network segmentation

Six VLANs, one job each.

Inter-VLAN rule: default deny, with a small allow-list for management traffic. VLAN 50 is the only escape hatch, used when something is broken and the VPN itself needs to be diagnosed.

5. What I learned

The point of the project was the learning, not the destination. Most lessons came from breaking things.

Technical skills acquired

Mistakes that taught the most

Surprises

• The default gateway is still WAN, not the VPN. Counter-intuitively, this is correct: the encrypted VPN packets themselves need WAN to reach Mullvad's servers. Zero-leak comes from firewall rules, not the default route.
• Mullvad reuses the same DNS IP across servers. 100.64.0.31 is anycast: the IP is identical everywhere; the tunnel decides which physical server answers.
• VLANs are a router feature, not a switch feature. The switch only tags frames; the firewall enforces who can talk to whom.

6. Limitations

Honest about what does not work yet.

7. Tooling and documentation

Everything that is not a private key lives in a public git repository. The repo is structured so a stranger could reproduce the lab from scratch:

configs/             # Markdown breakdowns of each pfSense and switch config
diagrams/            # Network and VLAN diagrams (PNG)
docs/                # Long-form writeups, this article, PDF manuals
configs/ccna-lab/    # Cisco gear isolated documentation
configs/mac-mini/    # Application host setup

Each commit corresponds to a single, named change. The git log is itself a learning journal.

8. Conclusion

A privacy-first home network is buildable on consumer-grade hardware for under $1,000 in core gear, given patience and a willingness to break things. The hard part is not the equipment, it is the discipline:

• Default-deny inter-VLAN traffic, override only when you can justify why.
• Verify every claim with a test (DNS leak check, kill-switch test, failover drill).
• Document the reasoning, not just the settings, so future-you remembers.
• Accept that the project is never "done"; it is a continuously refined practice.

The biggest takeaway: privacy is not a feature you install. It is a property that emerges when every layer of the network is configured to deny by default and prove it.

Appendix: Related reading in the lab repo

• README - project landing page
• firewall-rules.md - per-VLAN firewall chains
• nat-rules.md - the 12 outbound NAT rules that enforce the kill switch
• vpn-failover.md - WireGuard tunnel and gateway group design
• vlan-assignments.md - VLAN map and reasoning
• configs/ccna-lab - CCNA practice lab documentation
• configs/mac-mini - Docker host setup and remote access

Active draft. Suggestions and corrections welcome via the repo issues.