Network Segmentation: OpenWRT & VLANs
Migrating to a segmented three-VLAN architecture using OpenWRT, a managed switch, and enforced firewall.
Overview
The first major project in V2 was rebuilding the home network from scratch. Everything in V1 ran on a flat 192.168.1.x subnet shared with every device in the house, no segmentation, no isolation, and no trust boundaries. The goal for V2 was a fully segmented layout with isolated trust zones enforced at the firewall level.
This post covers the complete implementation: hardware selection, VLAN design, OpenWRT configuration, switch port assignments, firewall policy, and validation testing.
Hardware
| Device | Model | Role |
|---|---|---|
| Router | TP-Link Archer A7 (OpenWRT) | Gateway, VLAN routing, DHCP, firewall |
| Switch | NETGEAR GS308Ev4 | 8-port managed switch, 802.1Q VLAN tagging |
OpenWRT replaces the router’s stock firmware with a full Linux-based OS, unlocking VLAN support, custom firewall rules, and granular interface control that consumer firmware does not expose.
The GS308Ev4 is a managed switch supporting 802.1Q VLAN tagging — without this, wired VLAN segmentation is not possible. Unmanaged switches pass all traffic on a single broadcast domain regardless of router configuration.
VLAN Design
| VLAN | Name | Subnet | Purpose |
|---|---|---|---|
| 10 | Trusted | 192.168.10.0/24 | Personal devices: workstations, laptops, phones |
| 20 | Lab | 192.168.20.0/24 | Homelab infrastructure: servers, VMs, containers |
| 30 | IoT | 192.168.30.0/24 | Smart devices: NVR, cameras, appliances |
The firewall policy between zones is asymmetric by design. Trusted can reach Lab (for SSH access), but nothing else crosses zone boundaries except internet-bound traffic.
Physical Port Layout
| Port | Connection | VLAN Delivery |
|---|---|---|
| Router LAN 1 | → Switch Port 1 (trunk) | Tagged VLANs 10, 20, 30 |
| Router LAN 2 | → NVR (direct) | VLAN 30 untagged |
| Switch Port 1 | → Router LAN 1 (trunk) | Tagged VLANs 10, 20, 30 |
| Switch Port 2 | → inspiron | VLAN 20 untagged |
| Switch Port 3 | → pavilion | VLAN 20 untagged |
| Switch Port 4 | → citadel | VLAN 10 untagged |
| Switch Ports 5–8 | Management reserve | VLAN 1 (default) |
Ports 5–8 were intentionally left on VLAN 1 as a dedicated management path. This was not planned initially, it became necessary after the switch management interface became unreachable twice during VLAN reconfiguration, needing factory resets both times. A lesson in maintaining out-of-band access.
[PLACEHOLDER: Physical port diagram showing router-to-switch trunk link, individual device connections, and VLAN tag/untag assignments per port]
OpenWRT Configuration
The swconfig Architecture
The Archer A7 uses the older swconfig internal switch model (as opposed to the newer DSA architecture). This distinction matters: swconfig requires configuring the internal switch chip separately from the software network interfaces. Configuring only the software layer is insufficient, both must be set up independently for DHCP and routing to function correctly.
Internal Switch Table
| VLAN | CPU | LAN 1 | LAN 2 | LAN 3 | LAN 4 | WAN |
|---|---|---|---|---|---|---|
| 1 | tagged | off | off | off | off | off |
| 2 | tagged | off | off | off | off | untagged |
| 10 | tagged | tagged | off | off | off | off |
| 20 | tagged | tagged | off | off | off | off |
| 30 | tagged | tagged | untagged | off | off | off |
The CPU port is tagged on all VLANs so OpenWRT can route between them. LAN 1 serves as the trunk to the switch. LAN 2 delivers VLAN 30 untagged directly to the NVR.
Network Interfaces
| Interface | Device | IP | DHCP Range | Notes |
|---|---|---|---|---|
| trusted | br-trusted | 192.168.10.1/24 | .100 — .199 | Bridge: eth0.10 + 5 GHz radio |
| lab | eth0.20 | 192.168.20.1/24 | .100 — .199 | Wired only |
| iot | br-iot | 192.168.30.1/24 | .100 — .199 | Bridge: eth0.30 + 2.4 GHz radio |
The trusted and iot interfaces use bridge devices so both the wired VLAN and WiFi radio share the same subnet. The lab interface is wired-only with no bridge needed.
Critical Issue: Bridge Device Syntax
On swconfig-based platforms, bridge blocks in /etc/config/network must be written as anonymous blocks. Named blocks are silently ignored by the netifd daemon. The bridge appears configured correctly but never functions, and no error is logged.
Correct format:
1
2
3
4
5
6
7
8
9
config device
option name 'br-trusted'
option type 'bridge'
list ports 'eth0.10'
config device
option name 'br-iot'
option type 'bridge'
list ports 'eth0.30'
Wireless radios join the bridge automatically via
option networkin/etc/config/wireless— they do not need to be listed as bridge ports.
Firewall Policy
Zone Definitions
| Zone | Input | Output | Forward | Forwards To |
|---|---|---|---|---|
| wan | reject | accept | reject | — |
| trusted | accept | accept | reject | wan, lab |
| lab | accept | accept | reject | wan |
| iot | reject | accept | reject | wan |
IoT Zone: Controlled Isolation
The IoT zone uses input reject to block all unsolicited inbound traffic to the router. However, this immediately prevents IoT devices from receiving DHCP leases or resolving DNS. Two explicit allow rules restore only those essential services:
1
2
3
4
5
6
7
8
9
10
11
12
13
config rule
option name 'Allow-DHCP-IoT'
option src 'iot'
option proto 'udp'
option dest_port '67'
option target 'ACCEPT'
config rule
option name 'Allow-DNS-IoT'
option src 'iot'
option proto 'tcp udp'
option dest_port '53'
option target 'ACCEPT'
These rules affect router input only, IoT devices can get an IP and resolve DNS but cannot initiate connections to anything on the internal network.
NVR Access Exception
One targeted exception was required: Nginx Proxy Manager (VLAN 20) needs to reach the NVR web interface (VLAN 30) to proxy it at nvr.jamcre.dev.
| Rule | Source | Destination | Port | Purpose |
|---|---|---|---|---|
| Allow-NPM-to-NVR | NPM container (VLAN 20) | NVR (VLAN 30) | TCP 80 | NVR web UI via reverse proxy |
The rule is scoped to a single source IP and destination port, keeping broader IoT isolation intact.
DNS Configuration
Pi-hole is advertised as the primary DNS server to all DHCP clients via dnsmasq:
1
dhcp-option=6,192.168.20.XX,1.1.1.1
This applies globally across all interfaces. IoT devices receive Pi-hole’s address but cannot reach it (firewall blocks IoT → Lab traffic), so their DNS falls back to Cloudflare automatically.
Validation
Every firewall path was tested after configuration:
| Test | Expected | Result |
|---|---|---|
| Citadel → Internet | ✅ Allow | Working |
| Pavilion → Internet | ✅ Allow | Working |
| Citadel → Pavilion (Trusted → Lab) | ✅ Allow | Working |
| Pavilion → Citadel (Lab → Trusted) | ❌ Deny | Blocked as intended |
| 5 GHz devices → VLAN 10 | ✅ Allow | Working |
| 2.4 GHz devices → VLAN 30 | ✅ Allow | Working |
| IoT apps → Cloud services | ✅ Allow | Working |
What’s Next
With the network segmented and verified, the next step is deploying core services on pavilion. Starting with a fresh Proxmox installation and Pi-hole for cross-VLAN DNS resolution.