# 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

Current live exception:
- this is still the target design, not the currently proven-safe lane for every Protect accessory
- a 2026-05-22 client-override attempt put the Wi-Fi chimes on the Camera lane, but they later had to be returned to Management/default `UniFi Wireless` because Protect health failed there
- future camera/security-lane work must preserve this documented exception until Protect connectivity is explicitly re-validated

## 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 (target design; current live exception keeps the Wi-Fi chimes on Management/default `UniFi Wireless` until Protect validation exists on the security lane)
- 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 only after explicit Protect-path validation proves that the Wi-Fi chimes stay healthy there
- 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