The homelab network: UniFi from gateway to access points

The network is the part of the homelab I touch the least, which is exactly how it should be. It is UniFi from the edge to the access points, managed from one controller, with a simple two-network split.

The hardware

Nothing exotic. The point of UniFi here isn't performance, it's that the whole network is one config, one dashboard and one place to look when something is wrong.

Topology

            internet
               │
        [ USG gateway ]
               │
        [ US-24 core ] ──── Proxmox node A (3 × 1 GbE LACP bond)
          │    │    └────── Proxmox node B
          │    └─────────── NAS
          │
   [ US-8-60W PoE ] ── access points
          │
   [ Flex Mini ] × 2 ── desk / living room

Proxmox node A connects with three NICs in an LACP (802.3ad) bond into the core switch. On the Proxmox side the bond backs a VLAN-aware bridge; on the switch side it's a port aggregate. The management IP of the host lives on a separate, unbonded NIC so a bond problem never locks me out of the hypervisor.

grep -E "Slave Interface|Aggregator ID|MII Status" /proc/net/bonding/bond0

Two networks, VLAN-aware bridges

The LAN is deliberately simple:

• Default/management network: hypervisors, network gear, the controller, clients
• Server VLAN: VMs and containers that provide services

Both Proxmox nodes use VLAN-aware bridges, so putting a VM on the server VLAN is one tag= on its NIC rather than another bridge per VLAN:

qm set <vmid> --net0 virtio,bridge=vmbr0,tag=<vlan>

Inter-VLAN traffic goes through the gateway, which is where firewall rules live. Two networks is enough to keep "things that serve" separate from "things that browse" without turning every change into a firewall exercise.

The controller is a VM

The UniFi Network application runs in its own small Ubuntu VM on Proxmox. I tried moving it into a container on a Docker host and stopped halfway: the containerised controller works, but re-pointing every device's inform URL is the kind of migration you do on a quiet Sunday, not in passing.

Reasons I keep it as a VM:

• Blast radius. Rebuilding a Docker host never touches the network config.
• Backups. The whole controller is one vzdump, plus UniFi's own autobackup.
• It's boring. It gets patched, it restarts, it keeps working.

DNS: two Pi-holes, one per node

Every client gets two DNS servers, both Pi-hole, one on each Proxmox node. The primary is the source of truth; an hourly cron job syncs gravity and config to the secondary and restarts it:

# on the primary, hourly
ssh secondary systemctl stop pihole-FTL
rsync -a /etc/pihole/{gravity.db,pihole.toml} secondary:/etc/pihole/
ssh secondary systemctl start pihole-FTL

That gives the secondary a two-second gap once an hour, by design. The primary stays up throughout, and clients fail over between them.

Local names for internal services are CNAMEs in Pi-hole pointing at the reverse proxy, so every internal service gets a real hostname and a real certificate (issued via DNS-01, so nothing has to be reachable from outside).

Wi-Fi

Four access points cover the house and the garden. A few things that made a real difference:

• 2.4 GHz channel plan by hand. Auto-channel had three of four APs stacked on channel 6 at 80–90 % utilisation. Fixing the radios to 1/6/11 is what finally made the Wi-Fi cameras stable, not anything in Home Assistant.
• Substreams for camera walls. Four HD streams at once over 2.4 GHz is too much. Dashboards pull the SD substream; recording keeps HD.
• Wired where possible. The PoE switch powers the APs; anything that doesn't move gets a cable.

Remote access

Remote access goes through a WireGuard VPN, and the home IP is kept current with Cloudflare DDNS. The public website runs on an external VPS behind Cloudflare, not at home.