Building a secure and flexible homelab network

I wanted a network where I could add services, experiment, and make mistakes without giving every new device the same access to the rest of the lab. Before deploying more applications, I worked on the router, switch, and wireless access point that everything would depend on.

The work replaced a MikroTik hEX with a hAP ax S, hardened a CRS326 switch, and migrated a GL-MT6000 running OpenWrt. Both the router’s radios and the separate AP now provide home, IoT, and guest Wi-Fi. The HP server running Proxmox remained a downstream dependency; deploying its applications was outside this phase.

This walkthrough follows the implemented configuration and saved checks through October 5, 2026. Role names replace real VLAN numbers, addresses, SSIDs, account names, and port assignments. The configuration maps are explanatory pseudocode, not device exports or commands to paste into a router. I separate configured controls from behavior that was actually tested.

1. Assign roles before configuring VLANs

I kept the ISP router upstream and accepted double NAT and maintenance downtime. Public applications and remote administration were outside the migration. The hAP became the routing and firewall boundary; the CRS and OpenWrt AP remained Layer 2 devices with IP forwarding disabled.

The first useful distinction was between management and administration. Management is where the infrastructure has its endpoints. Administration is where the operator connects from. Keeping them separate makes access an explicit router policy instead of a property every ordinary client inherits.

Other roles had gateway/DHCP configuration or future reservations. That did not mean services were running in them. I treated a reserved network, a working transport path, and an accepted application as separate milestones.

The diagram focuses on the network foundation. It omits physical port numbers, addressing, recovery subnets, and later workload-specific changes. The server link is shown for its management role.

2. Build only the trunks that are needed

A trunk needs an explicit list of the VLANs it carries. On the CRS, I enabled VLAN filtering and kept the AP trunk limited to management plus its three wireless client roles. The server’s four-link LACP bond initially carried management only, because there were no running workloads to connect.

This is the configuration shape, with operational identifiers removed:

CRS bridge
  VLAN filtering: enabled
  IP forwarding: disabled

AP trunk
  tagged roles: MANAGEMENT, HOME, IOT, GUEST

Server bond — foundation stage
  mode: LACP
  members: four physical links
  tagged role: MANAGEMENT

Unused switch ports
  administrative state: disabled
  production bridge membership: none

I initially wanted permanent debugging ports for every VLAN, then withdrew that request. A temporary access port can be created for a specific test. Keeping unused ports disabled and outside the production bridge makes the normal state easier to inspect.

The switch also has DHCP snooping enabled, with the router uplink trusted, and BPDU guard on the remaining ordinary access port. Its own IP input and output policies end in default deny. Those settings are implemented; the rogue-DHCP, wrong-tag, and BPDU fault tests remain open.

Three configuration layers need to agree: bridge VLAN membership carries the traffic, a router VLAN interface provides a routed endpoint, and firewall rules decide which routed conversations are permitted. Creating one of those does not complete the other two.

3. Separate router services from forwarded traffic

I kept traffic to the router separate from traffic through the router. DNS or an administrative SSH session to the hAP belongs to the input policy. A client reaching the internet or a different VLAN belongs to the forward policy. Both finish with default deny, after established-connection handling and explicit exceptions.

The configuration work can be read as two related checklists:

Rule ordering mattered during DHCP acquisition. A client requesting its first address must reach that exception before input source validation rejects it. Once addressing exists, the ingress VLAN and expected source prefix are part of the checks. Prefix validation is useful, but it does not authenticate an individual device.

The following map summarizes intent rather than reproducing the complete rule order or every exception:

TO ROUTER
  Handle existing connections and explicit service exceptions.
  Permit initial DHCP acquisition before input source validation.
  Constrain administration and physical recovery by source and service.
  Deny anything not explicitly permitted.

THROUGH ROUTER
  Validate source prefixes against their ingress VLAN.
  Apply existing-connection handling and named exceptions.
  Permit selected administration and client traffic.
  Apply WAN destination and ordinary DNS/NTP restrictions.
  Deny anything not explicitly permitted.

Home and guest clients have general internet permission; IoT does not. These are routed-policy choices. They do not establish complete isolation between peers sharing a VLAN, since that traffic does not have to pass through the router.

4. Make addressing, DNS, and time part of the baseline

I wanted everyday network use eventually to survive the HP server being off. For the current baseline, DHCP advertises each VLAN’s router gateway as DNS and the router as NTP. The switch also uses router DNS and time.

On the hAP, DNS uses certificate-verified DNS over HTTPS with a static bootstrap record. The router’s own plaintext DNS fallback is blocked. Its NTP client and server functions are enabled, with an IP bootstrap and named upstreams.

Client lease
  DNS: router gateway for that VLAN
  NTP: router

Router resolver
  upstream: DNS over HTTPS
  certificate verification: enabled
  bootstrap: static record
  plaintext fallback: blocked

Router time
  NTP client: enabled
  NTP server: enabled

Saved cutover checks cover DNS over both UDP and TCP and served NTP. A later review recorded synchronized router and switch time. These results do not establish every client’s time configuration or prove all DNS behavior during a server outage.

A separate network is reserved for a future low-power services fleet. Its gateway remains disabled, with no DHCP scope or commissioned host. Independent hardware would address the HP dependency; a distinct VLAN would give those services their own routed policy boundary. The router and switch would remain shared dependencies. A controlled HP-off test, private DNS equivalence, and independent alert delivery are still pending.

5. Map wireless profiles to the same network roles

The hAP radios and OpenWrt AP use matching home, IoT, and guest roles. OpenWrt bridges the client VLANs over wired backhaul, with production management separate from its physical recovery connection. It does not take over routing.

The radio profiles make the compatibility exception visible:

WPS and fast transition are disabled. Guest and IoT profiles include client-isolation settings, but complete peer isolation across both APs still needs testing. Matching network names alone also does not prove good roaming.

The starting radio plan uses 20 MHz channels on 2.4 GHz and separate 40 MHz blocks on 5 GHz. I deferred the 40/80 MHz comparison until the AP’s final placement. There is no measurement establishing 40 MHz as optimal, and it was not a security requirement.

The most useful fault was physical. Guest connectivity worked, but home and IoT clients failed to obtain addresses. An intermediate TL-SG108E, absent from the assumed topology, was then found in the AP’s cable path. After bypassing it with a direct CRS connection, all three roles passed the recorded checks, including acceptance after reboot.

That result supports the topology change. It does not identify a particular setting or hardware defect on the intermediate switch. My first step next time would be to inventory every device in the cable path before changing more rules.

6. Change one stage at a time, with a recovery path

The work progressed from router bench preparation to cutover, AP migration, switch hardening, and account separation. The old router stayed available during bench work. Once the AP and switch had changed, reconnecting it was no longer a complete rollback for the network.

Each network device has its own dedicated physical recovery interface on a separate subnet. Alongside that access, I used the following mechanisms:

The rollback cases were real: one Safe Mode holder closed early, and another change failed short-run validation. The final activation released Safe Mode explicitly. The saved batches are dated, state-dependent changes; they are not an unattended installer to replay against any starting configuration.

I also separated daily key-based router administration from an emergency account restricted to physical recovery. Account source restrictions and IP service/firewall restrictions were configured, and the original administrator was retired after fresh daily-account checks.

The new emergency login remains an open test. An earlier report said it had passed, but later review found insufficient corroboration. I could not repeat the physical test then and chose to proceed. Earlier recovery access does not prove that the new account works.

MikroTik binary backups were encrypted; the OpenWrt configuration archive was not. Full restoration remains untested. A saved backup and a successful restore are different checkpoints.

7. Test the client path and record the gaps

For each stage, I wanted evidence beyond a management page loading. The saved checks cover concrete client behavior, with these limits:

Server management reachability is a narrower result than server or workload acceptance. The recorded SSH banner and HTTPS response establish connectivity; the HTTPS probe did not validate the certificate. No application deployment is being claimed here.

Laptop-based switch/AP observers were active at review. A permanent independent collector and confirmed notification delivery were not established. SSO, PKI, VPN, and central monitoring remain future work. Transition exceptions and temporary credentials also need deliberate retirement, and the review retained unresolved router management-service scope findings.

The useful result is a working baseline with explicit roles and a repeatable way to assess the next change: identify the required transport, define the permitted conversation, preserve recovery, and test from the actual client. The unfinished checks are part of that record.

Prepared with AI assistance from reviewed project notes and decision records. The interactive diagrams are explanatory models of the documented design. Recorded checks are historical, not live telemetry.