Project · Phase 1 complete

Segmented home network with whole-house VPN

Design, build, and ongoing operation of a personal home network. As of November 10, 2026, America/Chicago. No public IPs, internal addresses, VPN keys, serials, firmware revisions, SSIDs, passwords, or home location.

Problem

A typical home network is one flat subnet: laptops, phones, cameras, IoT, guests, and lab VMs can all reach each other, and a single compromised device can scan everything else. Consumer default-allow Wi-Fi also makes it easy for clients to bypass intended DNS and VPN policy.

I wanted a household network that behaves more like a small, documented enterprise edge:

• Traffic between roles is denied unless a rule allows it
• Cameras cannot reach the internet
• Guests and IoT cannot reach workstations or servers
• Outbound internet from the zones that are allowed online goes through a VPN, with a kill switch that was actually tested
• Clients cannot quietly switch to their own DNS

Design

Edge router: a GL.iNet Flint 2 running OpenWrt. The upstream gateway is in bridge mode, so the Flint 2 is the network edge (no double NAT).

Admin access is restricted to the trusted VLAN over SSH keys and HTTPS.

Switching: a TP-Link managed switch carrying an 802.1Q trunk to the Flint 2, so wired VLANs terminate on the OpenWrt firewall rather than in one L2 domain. Access ports are assigned to the seven segments below, including reserved PoE ports for a later camera install. A client on a lab access port received a lab-segment address, which confirmed the trunk.

VPN: Mullvad WireGuard as a whole-house VPN on the router. Trusted, lab, servers, IoT, DMZ, and guest egress through the VPN. The camera segment has no internet and is not sent through the VPN.

DNS: the router is the household resolver. Upstream is the VPN provider’s blocking DNS (ads, trackers, and malware), not a separately maintained local blocklist. Plain DNS is forced through that resolver, DNS-over-TLS is blocked, and well-known public resolvers are rejected so clients cannot skip policy.

Wi-Fi: three networks, for trusted, IoT, and guest, using SAE-mixed security on 2.4 GHz and 5 GHz. Guest client isolation is on and was verified. SSID names are omitted here.

Segments

Seven zones, each with a distinct role. Addressing is omitted from this public write-up.

A camera recorder path is planned, not built: PoE cameras on the camera segment and a recorder on the servers segment. No cameras-to-servers allow rule is in place yet, and the cameras are not installed.

Controls

• Default-deny zone firewall on OpenWrt. Zones map to the VLAN interfaces. Every non-trusted zone is input and forward reject, except DNS and DHCP.
• Trusted can forward to all zones. The reverse is not allowed: lab-initiated traffic to trusted is not an allow rule, and non-trusted forward is rejected.
• Whole-house WireGuard. The six segments listed above egress through Mullvad. Cameras do not. The kill switch is fail-closed: direct forwards to the raw WAN were removed, so if the tunnel is down, that traffic is not spilled around the VPN.
• IPv6 is disabled so it cannot bypass the IPv4 kill switch (no IPv6 on the WAN, and no IPv6 address assignment on the LAN).
• Forced DNS and encrypted-DNS blocking, as described above, plus household filtering at the resolver rather than in a single browser plugin.
• Admin hardening: SSH keys and HTTPS, restricted to the trusted VLAN. No admin credentials, keys, or management addresses appear in this write-up.

How it was tested

These are the tests that were actually run or verified in configuration as of November 10, 2026 (America/Chicago):

1. Trunk / segmentation (partial). A client on a lab access port received a lab-segment address. Guest Wi-Fi client isolation was verified.
2. Camera zone policy. The camera segment has no WAN and is not forwarded to the VPN in the firewall config. Cameras are not installed yet, so this is a policy check, not a live camera test.
3. Kill switch. Direct WAN forwards were removed, then verified by taking the VPN interface down and back up. IPv6 is disabled as the bypass control.
4. Forced DNS / DoT. DNS redirects, DNS-over-TLS blocks, and public-resolver rejects are in place on all zones. After those rules, a client DNS leak was fixed and a VPN leak test was clean.
5. Filter sanity. A known ad/tracker domain returned NXDOMAIN through the blocking resolver.
6. Admin path. Admin access was verified as key-only SSH and HTTPS, restricted to the trusted VLAN.

What I learned

• Default-deny only helps if every interface, including Wi-Fi and every switch port, is in the right zone. A single untagged port can undo a weekend of VLAN work.
• A VPN without a kill switch is a policy suggestion. The failure mode that matters is “tunnel down, traffic still leaving the WAN,” including IPv6 — which is why IPv6 is disabled here and the WAN forwards were removed, then tested.
• DNS policy is part of the firewall. After a client leaked DNS, forced DNS, DNS-over-TLS blocks, and public-resolver rejects were required to make the policy actually stick.
• Documentation is a control. A zone matrix and a short test record are what make this transferable to a SOC or detection role, not a screenshot of the router UI.

What this write-up deliberately omits

Internal and public IP addresses, subnet maps, management paths, exact firmware and hardware revisions, Mullvad account or key material, peer hostnames, router or switch serials, SSID names, passwords, key paths, and any floor plan or city beyond what is already on the public GitHub profile (United States).

Related work

• Home SOC lab — Wazuh and host controls on the lab segment
• network-monitoring — Python lab tooling for inventory checks, DNS drift, and alerting (lab topology; not this home network)