Files
truenas-stacks/home/doris-dashboard/docs/network-redesign-plan.md

215 lines
6.1 KiB
Markdown

# Home Network Redesign Plan
> For Doris: this is the target architecture and migration plan that the interactive site visualizes.
Goal: redesign John's home network and homelab into a simpler, future-proof VLAN model that supports camera growth, cleaner firewall policy, better Wi-Fi placement, and easier operations.
Architecture summary:
- Collapse historical clutter into six intentional VLANs.
- Separate user devices, servers, infrastructure, IoT, guests, and cameras/security.
- Move all non-infrastructure devices off Management.
- Retire Old IoT after staged migration.
- Add the downstairs U6 LR back into service if coverage or roaming needs it.
## Target VLANs
1. Infrastructure / Management
- VLAN 10
- Subnet: 10.5.10.0/24
- Contains: UDM, switches, APs, management IPs, controller-facing infra, OOB/admin surfaces
- Policy: only Trusted admin devices and designated server tooling may initiate into this VLAN
2. Trusted Clients
- VLAN 20
- Subnet: 10.5.20.0/24
- Contains: phones, tablets, laptops, handhelds, Steam Deck, personal endpoints
- Policy: can reach Servers and selected admin surfaces; not a dumping ground for random smart devices
3. Servers / Core Services
- VLAN 30
- Subnet: 10.5.30.0/24
- Contains: PlausibleDeniability, Serenity, Nomad, Rocinante, FlyingDutchman if it is a real service host
- Policy: tightly controlled east-west; explicit service exposure to IoT/Camera where needed
4. IoT / Smart Home
- VLAN 40
- Subnet: 10.5.40.0/24
- Contains: ecobees, appliances, MyQ, Google Home-class devices, legacy smart junk worth keeping
- Policy: default deny to internal networks except DNS, NTP, specific server services, and carefully allowed discovery flows
5. Guest
- VLAN 50
- Subnet: 10.5.50.0/24
- Contains: visitor and untrusted BYOD devices
- Policy: internet only, client isolation on Wi-Fi
6. Cameras / Security
- VLAN 60
- Subnet: 10.5.60.0/24
- Contains: doorbell, Protect chimes, future cameras, NVR-adjacent accessories, security-specific Wi-Fi endpoints
- Policy: no broad access to LAN; only specific flows to Protect/NVR services and operator/admin clients
## SSID Plan
Preferred steady-state SSIDs:
- Trusted: one main trusted SSID
- Trusted-Compat: optional temporary fallback for stubborn devices only
- IoT: one dedicated smart-home SSID
- Guest: one guest SSID
- Security: one dedicated SSID for Wi-Fi doorbells/chimes/cameras if needed
Mapping recommendation:
- Trusted SSID -> VLAN 20
- Trusted-Compat SSID -> VLAN 20 (temporary or policy-reduced fallback)
- IoT SSID -> VLAN 40
- Guest SSID -> VLAN 50
- Security SSID -> VLAN 60
Current-name migration suggestion:
- Yer a Wifi Harry -> Trusted
- Whiskey Neat Fuck Ice -> temporary Trusted-Compat or retire later
- CIA Via -> repoint to IoT during migration, then decide whether to keep or rename
- UNEF's Playhouse -> Security / Cameras
## Device Placement Recommendations
Infrastructure / Management:
- UDM Pro
- USW Pro HD 24
- USW-24-PoE
- U7 Pro
- U6 LR
- other management-only appliance interfaces
Servers / Core Services:
- PlausibleDeniability
- Serenity
- Nomad
- Rocinante
- FlyingDutchman if used as a real service host
Trusted Clients:
- phones
- tablets
- handhelds
- laptops/desktops
- Steam Deck
IoT / Smart Home:
- Main-Floor ecobee
- Upstairs ecobee
- MyQ
- Samsung FamilyHub
- LG dryer
- Google Home Mini
- Google / Chromecast-class devices
- retained legacy smart devices
Cameras / Security:
- front-doorbell
- Protect chimes
- future wired/PoE cameras
- future Wi-Fi security accessories
## Wi-Fi and AP Placement
Primary AP design:
- U7 Pro remains active as the main upstairs AP.
- Reinstall the U6 LR downstairs if downstairs coverage, roaming, or camera/IoT RSSI is weak.
- Prefer wired backhaul for both APs.
Operational stance:
- Do not overcomplicate RF tuning on day one.
- First restore dual-AP coverage, then evaluate channels, transmit power, and minimum RSSI with real client behavior.
- For growing cameras/security footprint, bias toward wired PoE cameras on the Cameras VLAN when practical.
## Firewall Intent
Trusted -> Management
- allow only designated admin devices/services
Trusted -> Servers
- allow
Trusted -> IoT
- limited allow for control/discovery as needed
Trusted -> Cameras
- allow operator/admin access
Servers -> IoT
- allow only explicitly needed services
Servers -> Cameras
- allow Protect/NVR-related flows only
IoT -> internal networks
- default deny
- explicit allow to DNS, NTP, specific server services, and required discovery helpers only
Cameras -> internal networks
- default deny
- explicit allow to Protect/NVR, time, DNS, and update paths only
Guest -> internal networks
- deny
Management -> internet
- only what infrastructure actually needs
## Migration Order
Phase 0: groundwork
- create target VLANs and port profiles
- stage firewall rules
- stage target SSIDs
- document rollback points
Phase 1: infrastructure cleanup
- move all infra to Management VLAN 10
- remove non-infra clients from management
- verify switch/AP/gateway management reachability
Phase 2: servers
- move core hosts to Servers VLAN 30
- confirm service reachability from Trusted
- update DNS/static mappings/firewall rules
Phase 3: cameras/security
- move doorbell and chimes to VLAN 60
- prepare room for future camera growth
Phase 4: IoT migration
- move active smart-home devices from Old IoT into VLAN 40 in batches
- start with easiest cloud-managed devices, then thermostats, then Google ecosystem devices
Phase 5: SSID simplification
- retire Old IoT SSID after validation
- collapse or retire temporary Trusted-Compat if not needed
Phase 6: cleanup
- remove Old IoT VLAN 2
- remove stale port profiles
- remove stale firewall rules and historical exceptions
## Port Profile Set
Maintain only intentional profiles:
- trunk-uplink
- access-management
- access-trusted
- access-servers
- access-iot
- access-guest
- access-cameras
## Success Criteria
- Management contains infrastructure only
- Old IoT is retired
- Cameras/Security has room to grow now, not later
- VLAN purpose is obvious at a glance
- Wi-Fi SSIDs reflect policy, not historical accidents
- Firewall rules match intent and are explainable
- A tired operator can still understand the network at 2 AM