Infrastructure/docs/status.md

Homelab Network Overhaul — Status & Decisions

Living document. Update checkboxes and tables as things change instead of re-deriving this from scratch each time.

Location: Linz, Austria. ISP: LIWEST (cable). Modem: Technicolor CGA4233-EU.

Current TODO

See todo.md for the live checklist. Quick status (as of 2026-09-26): bridge mode, controller adoption, firmware update, VLANs, ACLs, WireGuard VPN + INWX DynDNS, the SG2016P switch, all three SSIDs, NAS on Servers with QuickConnect disabled, and NPM/Pi-hole local naming are all done. In progress: the first Hyper Backup of the NAS. Next: second AP + living-room switch (purchase decided), office AP ceiling mount + Wi-Fi re-measure, partner's Synology app logins, hardware shopping list. Everything else is waiting on the NUC.

Hardware decisions

Network core

Item	Model	Status
Router	TP-Link Omada ER605 v2.30, firmware 2.4.5	Received, adopted, updated
Main switch	TP-Link Omada SG2016P (16-port, 8×PoE+, 120W budget)	Received, adopted, wired in; powers the office AP via PoE (make sure the AP is in an actual PoE port — only 8 of the 16 are)
Access point #1	TP-Link Omada EAP650	Received — mounting in the office first, powered via its own DC adapter until the switch's PoE+ is available
Access point #2	TP-Link Omada EAP650 (same model as AP #1)	Decided to buy — chosen over the EAP610 (AX1800, no 160 MHz on 5 GHz) so both APs are identical; the peak-speed difference is irrelevant to the actual couch problem, which is signal quality. Living-room/dining-area coverage, mounted above the TV (see Wi-Fi section)
Living-room switch	TP-Link Omada ES205GP (5-port, 4× PoE+ 802.3at/af, 65W budget)	Decided to buy — note the P: the plain ES205G in earlier notes has no PoE. Easy Managed tier, but supports 802.1Q VLANs (up to 32 groups) via Omada Controller, adopted like the other devices. 3 devices need ports (AP, TV, streaming Pi), so 5 ports is plenty — no need for an 8-port unit

Homeserver

• Used Intel NUC (8th-gen Core i3, 16GB DDR4, 128GB SSD), bought via Willhaben for ~€155 — replaced the original new-Beelink-EQ14 plan.
• OS: plain Debian/Ubuntu + Docker Compose. No Proxmox/hypervisor.
• Home Assistant via the official "Home Assistant Container" image (not Home Assistant OS) — matches running everything else as plain Docker.
• Config management: Ansible, run from David's own machine over SSH (no footprint on the server itself).
• Kubernetes explicitly rejected for home services (no benefit on a single node). Will build a separate k3s learning cluster later on already-owned Raspberry Pis (RPi4 and older), kept fully separate from production services — motivated by wanting K8s reps for work, not by home-service needs.

Living room

• Single existing Ethernet cable feeds this area from the wall. Plan: run that connection to a spot above the TV, and put the new ES205GP switch + second AP (EAP650) there, so the TV and streaming Pi are each only a short patch cable away. (Alternative considered and rejected: switch + AP at the wall outlet above the cabinet, which would need two ~5 m runs to the TV and Pi instead of one longer run.)
• Connected there: the second AP (EAP650, PoE-powered from the ES205GP — no separate adapter), the TV (wired, on IoT), and the Raspberry Pi for game streaming (on Trusted).
• VLAN plumbing this needs: the ES205GP uplink port and the AP's port are trunks carrying Trusted (10) / IoT (20) / Guest (40) tagged; TV port = access port on IoT; Pi port = access port on Trusted. The SG2016P port feeding this cable must be a matching trunk (remember the lesson from the first AP: every VLAN needs to be tagged on every hop between the AP and the ER605, or clients associate but never get an IP).
• Streaming Steam games to the TV: try the already-owned RPi4 with Moonlight first (well-proven, hardware-decode, zero cost) before buying anything. Fallback if insufficient: new RPi5 (~€150) or a cheap N100 mini PC (similar price, more flexible, slightly higher latency/idle power).
• Streaming Pi should sit on the Trusted VLAN (same as the gaming PC) to avoid an unnecessary routing hop.

Full wired device list (needs a switch port)

Linux PC · Windows gaming PC · partner's PC · printer (optional) · Synology NAS · homeserver (NUC) · OctoPrint Pi · AP (via living-room switch) · streaming Pi (via living-room switch)

Network architecture

VLAN plan

VLAN	Subnet	Purpose
10 — Trusted	192.168.10.0/24	Personal devices, PCs, streaming Pi (avoids an extra routing hop for game streaming)
20 — IoT / Home Automation	192.168.20.0/24	OctoPrint + webcam, sensors, light bulbs, camera, robot vacuum, TV — internet allowed (needed for TV streaming apps + vacuum's cloud control), LAN access denied by ACL
30 — Servers / Homelab	192.168.30.0/24	NAS, homeserver (NUC)
40 — Guest	192.168.40.0/24	Isolated (Omada "Isolate Network" flag), internet-only
99 — Management	192.168.99.0/24	Switch/AP/controller control plane

• Window/door/temperature sensors are Zigbee via a USB coordinator on the homeserver, not IP devices — they never touch VLAN 20's network; Home Assistant talks to them over the local Zigbee radio directly.
• Default-deny between VLANs is not automatic on Omada — inter-VLAN routing is allow-all by default; ACL rules must be built manually (e.g., Home Assistant → IoT devices).
• ACL direction for alerts/control is Servers → IoT (Home Assistant reaching in to poll/control devices), not the reverse — IoT devices never need to initiate connections out to notify anyone.
• TV casting only needs Trusted → IoT allowed (the casting source connects out to the TV); return traffic flows back automatically as part of that established connection, no reverse rule needed. Discovery is handled by the ER605's mDNS repeater.
• ACL rules built (Omada ACL types: Network = exact match, !Network = any network except the one picked; Direction LAN-LAN vs LAN-WAN vs WAN-IN are separate scopes — a LAN-LAN rule has zero effect on internet access):
  • Network: IoT → !Network: IoT, Direction LAN-LAN, Deny — one rule blocks IoT from reaching every other VLAN (Trusted/Servers/Management/Guest) at once; internet access for IoT is untouched since WAN isn't in scope for a LAN-LAN rule.
  • Network: Servers → Network: Management, Direction LAN-LAN, Deny.
  • Network: Guest → Network: Management, Direction LAN-LAN, Deny (defense-in-depth alongside Guest's Isolate Network flag).
  • Everything else (Trusted↔Servers, Trusted→Management, Servers→IoT, Trusted→IoT, all internet access) relies on Omada's allow-all-by-default behavior — no rule needed.
• WAN-IN rules generally aren't needed — NAT already blocks all unsolicited inbound traffic by default; WAN-IN only matters for scoping something you've already port-forwarded (e.g. the VPN port).
• ER605 supports full per-port 802.1Q tagging/untagging/PVID; no practical VLAN-count limit for this setup.
• ER605's built-in mDNS repeater bridges Bonjour/mDNS discovery across VLANs (relevant for reaching OctoPrint/HA by local hostname).
• ER605's LAN DNS feature (firmware 2.3.0+) allows manual local hostname → IP entries — but like all DNS, it cannot encode a port number. Non-standard-port services (OctoPrint:5000, HA:8123, Omada Controller:8043, Spoolman:7912, Portainer:9000, etc.) still need a reverse proxy for clean no-port URLs.

Wi-Fi

• Router is headless by design (lives in a cupboard — its own Wi-Fi radio would be useless there anyway).
• First AP (EAP650) is in the office. Measured signal (interim position, AP on top of a closet — not yet at its final ceiling mount): office desk -42 dBm, office at the 3D printer -39, master bedroom -42, kitchen -57, storage room (door closed) -59, living-room couch -70 (matches a measured drop from ~50 to 10-20 Mbit there). Coverage is good everywhere except the couch nook, which sits behind the bathroom and hallway walls relative to the office. Rough thresholds: better than -60 good, to about -67 reliable for streaming/calls, -70 marginal, worse than -75 weak.
• Decision: add a second AP (EAP650) in the living/dining area, mounted above the TV — a single weak spot alone wouldn't have justified it (phone use at -70 is fine, and the TV/streaming Pi are wired), but David wants to keep working from the couch or dining table on a laptop, where -70 dBm is genuinely marginal. Wired backhaul, so no mesh needed.
• A ping to an idle phone is not a valid coverage test — phones in Wi-Fi power-save routinely show 100-500 ms round trips with a strong signal. Use the AP's own reading (Controller → Clients → the device's signal/link rate), a screen-on ping, or a throughput test instead.
• Worth re-measuring the couch once the office AP is at its real ceiling position and again after the second AP is up, for a before/after comparison.

VPN

• WireGuard runs on the ER605 itself, not on the homeserver — avoids extra port-forwarding + static routing that a NUC-hosted VPN would need. Working as of firmware 2.4.5.
• ER605 firmware must be at least 2.4.5 for WireGuard VPN Server to appear as an option in the Controller at all — on the pre-update firmware (2.3.3), WireGuard wasn't listed, and the OpenVPN server that was available silently never actually started (config looked correct in the Controller — enabled, user linked, no errors in Audit Logs — but the daemon never bound to its port, confirmed via ECONNREFUSED on local, WAN-direct, and external tests). Updating firmware fixed both.
• Local Networks scoped to Servers (30) + IoT (20) — remote access to the NAS/self-hosted services and things like OctoPrint, not to personal devices on Trusted. (Was briefly set to Trusted-only, then discovered to actually have every network selected — same "field silently left on all networks" class of bug hit earlier with OpenVPN's Local Networks. Corrected to the minimal actual-need scope: Servers + IoT, explicitly excluding Management for now — no current need for it, easy to widen later.) Tunnel Mode Split (only the selected networks' traffic goes through the tunnel, not general browsing).
• VPN client IP pool: 192.168.66.0/24 — deliberately outside all VLAN subnets, no fixed convention requirement (doesn't have to be a 10.x range).
• Needs its own port-forward rule (Settings → Transmission → NAT → Port Forwarding) separate from any VLAN/ACL config: WAN1, external+internal port 51820, internal IP 192.168.0.1 (the gateway's own Default-network address, since the VPN terminates on the gateway itself), protocol UDP or All — not TCP only (a real bug hit during OpenVPN testing: the port-forward was accidentally set to TCP-only while OpenVPN used UDP, causing a silent timeout that looked identical to "nothing is running" until diagnosed via matching local vs. external ECONNREFUSED signals).
• No additional WAN-IN ACL rule was needed on top of the port-forward — confirmed via the external test returning an active ECONNREFUSED rather than a silent timeout, which proves traffic was already reaching the gateway.
• Android: WireGuard/OpenVPN aren't part of Android's built-in VPN framework (that only covers IKEv2/IPsec and L2TP natively) — use the official WireGuard app (supports QR-code import — zoom the browser in if the phone camera won't scan it off a monitor) or OpenVPN Connect app.
• DynDNS instead of paying LIWEST for a static IP — real annual cost difference (~€200+/year for static IP vs. free DynDNS), and cable IPs don't change often in practice anyway. Decided against DuckDNS — David already owns a domain via INWX, which has its own DynDNS2-compatible service, so used that instead (no shared duckdns.org domain, and INWX's DomRobot API has a ready-made acme.sh plugin for future Let's Encrypt DNS-01 certs on NPM).
  • Set up an INWX DynDNS account (their control panel's dedicated DynDNS section, not general domain/DNS management) — this single step both creates the DNS record for the chosen hostname and generates a separate DynDNS-scoped username/password (not the main INWX account login — narrower blast radius if it ever leaked).
  • Configured on the ER605 via Device Config → Gateway → DNS → Dynamic DNS, Service Provider Custom:
    • Update-URL: https://[USERNAME]:[PASSWORD]@dyndns.inwx.com/nic/update?hostname=[DOMAIN]&myip=[IP] (Omada's Custom DDNS placeholders — substituted from the Username/Password/Domain Name fields, not typed literally into the URL)
    • The actual filled-in URL/credentials are not written anywhere in this repo — keep them out of anything committed.
  • Working — verified via dig +short <hostname> returning the ER605's current public IP.
  • WireGuard client Endpoint doesn't auto-update to a hostname from the Controller UI (it always embeds the raw WAN IP in exported configs) — WireGuard's config format supports hostnames in Endpoint natively though, so just manually edit the line (in the downloaded .conf or directly in the WireGuard app's peer settings) to Endpoint = <hostname>:51820 after generating a client config.
• General WireGuard gotcha, same shape as the Endpoint one above: fields set on the server config (e.g. Primary DNS Server) do not retroactively apply to peers whose config was already generated/imported before the change — WireGuard bakes settings into the client's config at generation time, it isn't pushed live the way DHCP options are. After changing a server-side field, either regenerate and re-import the client config, or edit the existing peer directly in the WireGuard app (same trick as the Endpoint fix).
• Bridge mode confirmed active on the modem — ER605 WAN gets the public IP directly (see TODO above).

Local DNS & naming

• Naming scheme settled on: <name>.home.staffenberger.at — a subdomain of David's own already-owned INWX domain, not .local (reserved for mDNS/Bonjour, RFC 6762 — using it for manual DNS records risks conflicting with automatic mDNS resolution) and not .home or .home.arpa (the latter is the IETF-correct reserved suffix per RFC 8375, but rejected as too unfriendly for the partner to read/type). These records exist only in Pi-hole's local DNS — never published to INWX's real public DNS, so nothing is internet-exposed by using a real owned domain for the naming.
• Records added so far as individual Local DNS Records in Pi-hole (not yet the wildcard approach — see TODO): pihole.home.staffenberger.at, nas.home.staffenberger.at, both pointing at the NAS's Servers-VLAN IP (192.168.30.10).
• Gotcha: a secondary/fallback DNS server on a VLAN's DHCP config causes intermittent resolution failures for internal-only names. Trusted's DHCP had Pi-hole as Primary DNS but 8.8.8.8 (Google public DNS) as Secondary — client OS resolvers don't reliably always-prefer-primary (can race/round-robin), so any query that happened to hit 8.8.8.8 for an internal .home.staffenberger.at name failed immediately, since a public resolver has no knowledge of it. Symptom looked like "works for me, not for my partner" / inconsistent across devices. Fix: don't set a secondary DNS pointing outside Pi-hole at all — Pi-hole already forwards normal internet lookups upstream itself.
• Same stale-DHCP-lease pattern hit all week applies to DNS server changes too — a device won't pick up a newly-configured DNS server until it renews its lease (Wi-Fi toggle, ipconfig /release+/renew, etc.), same as VLAN reassignment.

Omada Controller

• Self-hosted Omada Software Controller (Docker) instead of TP-Link's cloud controller — avoids a vendor cloud relay, in line with the general "no cloud relay" networking principle.
• Plan: run it temporarily on David's own Linux desktop now, adopt the ER605 immediately, then migrate to the NUC later via Omada's Controller Migration (backup/restore) feature once the NUC is set up.
• Watch for controller version mismatches between export and import — TP-Link/Omada requires matching major.minor(.patch) versions for restore; fallback is installing a specific matching version first, restoring, then upgrading.

Reverse proxy

• Chosen: Nginx Proxy Manager (NPM) — single GUI, single source of truth for all proxy configs, works uniformly whether the target is a Docker container on the NUC or a bare-metal service elsewhere (e.g. OctoPrint on the Pi).
• Traefik considered and rejected for home use (label-based config fights against wanting one central place to look); will get real Traefik exposure anyway via the k3s learning cluster, where it's the default ingress controller.

Switch port configuration (SG2016P)

• Access port = one VLAN, untagged — for every VLAN-unaware end device (PCs, NAS, printer, Pis, TV). Set the port's Native/Untagged network to the device's VLAN and leave Tagged empty; don't leave Default involved. Trunk = several VLANs tagged over one cable — only for infrastructure links (switch↔router, switch↔AP).
• Every VLAN must be tagged on every hop between an AP and the ER605, or clients associate to the SSID but never get an IP ("IP configuration failure"). Hit this twice: the first AP's port, then the switch's uplink to the ER605 (missing VLAN 10). The per-Network "Select Device Port" step and the per-port VLAN config are two views of the same thing; editing the port directly avoids the "cannot deselect the interface which selects the LAN as PVID" error.
• The AP's port native/untagged VLAN and the switch/AP management traffic deliberately stay on Default for now (same L2 segment as the Controller on David's desktop) — migrate management to VLAN 99 together with the Controller move to the NUC, at which point Default can be retired.
• Extra safety net: Guest VLAN also enabled on the currently-used ports so anything unexpectedly plugged in lands isolated.
• After any port/VLAN or DHCP-scope change, a device keeps its old lease until it renews: toggle the port off/on in the Controller (equivalent to unplugging), ipconfig /release+/renew on Windows, or Wi-Fi off/on on phones.
• The Network column in the Controller's Clients list is blank for wireless clients — cosmetic; the client's IP range is the real check of which VLAN it landed in.
• Switch PoE is only on 8 of the 16 ports; a "dead" AP was just plugged into a non-PoE port (and then needed a minute to boot).

Backups

• Omada Controller: auto-backup enabled, daily for now (config is changing a lot; switch to weekly later). Local only on the Controller host for now — backups live in the container's data volume, so docker compose down -v deletes them. Off-machine rsync copy to a dedicated, quota-limited Synology user is deferred until the NUC migration (see todo.md). Backups contain secrets (Device Account, WireGuard keys, DDNS settings) — never commit them.
• Synology NAS → 6TB USB drive via Hyper Backup, deliberately manually connected (offline drive also guards against ransomware/accidental deletion), cadence every two weeks, recurring calendar reminder. Drive arrived as exFAT (DSM 7.3 mounts exFAT natively — the "exFAT Access" package no longer appears in Package Center — but exFAT has no journal, so an unclean unplug leaves a dirty flag and DSM reports "not ejected safely"); reformatted to ext4 via DSM (Control Panel → External Devices → Format — select the device row and Eject first if Format is greyed out). Hyper Backup has no plug-in trigger on DSM 7, so it's "plug in → Back up now → eject in DSM → unplug".
  • Wizard order is destination first, then sources. Backup type Multiple versions, Folders and Packages (not LUNs).
  • Sources: all shared folders (incl. photo, Drive team folders, docker) + homes (~200 GB) + all applications (Synology Drive Server and Photos matter most — they carry the version history / albums / metadata that plain file copies lose), config backup on, client-side encryption on (password in Enpass), no schedule, Smart Recycle retention.
  • homes is a reserved system share: its permissions can't be edited ("homes is reserved for the system"), and only Administrators-group accounts see it in Hyper Backup — neither is a problem.
  • Entire-system backup (restorable NAS image) isn't available to a local USB destination, only to a remote NAS / C2 — restoring means reinstalling DSM and packages and restoring data + config from the backup.
  • Still to confirm after the first run finishes: a test restore of a personal Drive file and a personal photo (both users) to prove the application backup really covers personal data. Later: occasional off-site copy (3-2-1).
  • Planned (post-NUC): power the drive via a Home Assistant smart plug for a weekly window instead of plugging it in by hand — goal is protection against hardware failure; the slightly weaker ransomware isolation is accepted (off-site copy if that ever matters). Power-off only after a scripted clean eject. Details in todo.md.
• Hyper Backup vs Hyper Backup Vault: Vault is only the receiving side on a second Synology (relevant for a future off-site copy), not needed for a local USB drive.

Cabling & power

• Cupboard patch cables: flat Cat6 is fine for short (2-3 m or less) data-only links — buy pure copper (CCA and very thin conductors are the risk), from a reputable maker (deleyCON flat U/UTP is AWG 27 stranded copper, unshielded, 1.5 mm thick, sold as 5-packs in white and individually in white/black, down to 25 cm; Goobay, InLine, Digitus/Delock are comparable). Unshielded is fine — twisted-pair geometry does the noise rejection. Flat cables are fragile where the cable meets the plug: no pull or sharp bend there. PoE runs (to the APs) and longer runs (e.g. to above the TV) should be round pure-copper cable, not flat. Verify each link shows 1000 Mbps in the Controller after swapping; a link that negotiates 100 Mbps or shows errors = swap the cable. (The TV port showed 100 Mbps earlier — probably the TV's own NIC, but unconfirmed.) Measure the real cable path with string and add 20-30 cm before choosing 2 m vs 3 m. Color-by-length coding isn't available in flat cables (only white/black) — use labels/Velcro, and a colored round multi-length set for loose spares.
• Socket strips (Austria: Schuko/Type F): a strip adds sockets, not capacity — plug two strips into different wall outlets, no daisy-chaining. Look for VDE/GS/ÖVE mark, 16 A, 3×1.5 mm² cable, surge protection for the PC/desk strip, and no switch (or a guarded one) for the router/switch/NAS strip. Mount with screws (keyhole slots/mounting plate), sockets facing sideways/down, never adhesive. The workshop-style metal strip David likes is bracket-mounted (Brennenstuhl Premium-Alu-Line is the closest wall-mountable match found; the AJ Produkte MOTION and Manutan ones are for their own workbench frames and only list CE, not VDE/GS).

Home automation plans

• Sensors: temperature/humidity, window-open monitoring, light bulb monitoring — via Zigbee-style sensors + a USB coordinator dongle (e.g. Sonoff Zigbee 3.0, ~€15–20) plugged into the homeserver.
• Camera to check on the cat: casual live viewing is computationally free. If smart detection (Frigate) is wanted later, add a Coral USB accelerator (~€70) rather than upgrading the CPU.

Planned services on the homeserver (NUC)

• Home Assistant (Container image)
• Pi-hole
• Filament spool manager (Docker)
• Omada Software Controller (Docker — migrated from the temporary desktop instance)
• Nginx Proxy Manager
• Self-written Docker tools (future)
• All managed via Ansible playbooks