sync: auto-sync from HOWARD-HOME at 2026-06-17 09:35:47
Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-17 09:35:47
This commit is contained in:
@@ -1,7 +1,14 @@
|
||||
# Cascades — Voice VLAN (VLAN 30) Cutover Runbook + Recon
|
||||
|
||||
- **Created:** 2026-06-16 (Howard-Home / claude-main)
|
||||
- **Status:** PLANNED — not yet executed. Vendor email sent 2026-06-16; awaiting Richard's confirm + maintenance window.
|
||||
- **Status:** APPROVED TO EXECUTE — Richard confirmed 2026-06-17 (go for VLAN build + device moves). Maintenance window still to be set for the live port flips.
|
||||
|
||||
## Vendor confirmation (Richard Turner, 2026-06-17) — materially simplifies the plan
|
||||
Richard replied "we are good to start." Two confirmations change the runbook:
|
||||
1. **Remote desktop gets its IP from DHCP** (not static, as recon had assumed). Verified on pfSense 2026-06-17: no static mapping for `e4:e7:49:52:3a:06` in ISC `dhcpd.conf`, but an active lease exists (`client-hostname "Vertical-Remote"`). => **Desktop cutover is zero-touch**: flip port 16 -> VOICE and it re-DHCPs onto `10.0.30.x`. No NIC change, no Vertical coordination needed for the desktop itself.
|
||||
2. **Vertical reaches the desktop via LogMeIn, NOT the pfSense OpenVPN.** => **Part A step 6 (OpenVPN Client-Specific-Override + his cert CN) is DROPPED.** LogMeIn is an outbound agent, so the desktop only needs internet egress on VOICE — already granted by firewall rule (d). This is also better for HIPAA: a LogMeIn session lands on the isolated voice VLAN with no path to PHI / main LAN / VLAN 20.
|
||||
|
||||
Also resolved: **DHCP backend = ISC dhcpd** (Kea config present but dormant), confirmed live 2026-06-17 — reservations placed out-of-pool (below .100) are safe.
|
||||
- **Driver:** Vertical (VoIP vendor, Richard Turner <RTurner@vertical.com>) cannot reach the phones from the remote-management desktop, and phone IPs drift. Root cause: when the network was segmented into VLANs, the Vertical remote desktop and the wired phones were left on the original LAN while the wireless phones landed on VLAN 20 — so the desktop has no path to the wireless phones (main-LAN -> VLAN 20 is blocked at pfSense).
|
||||
|
||||
## Goal
|
||||
@@ -63,11 +70,7 @@ Probed from CS-SERVER (`192.168.2.254`, same LAN segment) — read-only.
|
||||
- (b) **CONDITIONAL** PASS: VOICE net -> `<on-prem PBX IP>` SIP/RTP/provisioning. **Recon says SKIP (cloud PBX); add only if Richard confirms an on-prem PBX.**
|
||||
- (c) BLOCK: VOICE net -> `RFC1918`. (isolation)
|
||||
- (d) PASS: VOICE net -> any. (internet)
|
||||
6. **OpenVPN — reach desktop on VOICE, scoped to voice only:**
|
||||
- His `.ovpn` does NOT need re-export (routes are server-pushed; same host/port/cert) — he just reconnects.
|
||||
- Preferred: VPN -> OpenVPN -> **Client Specific Overrides** for **Richard's CN**: IPv4 Local Network/s = `10.0.30.0/24` only; give him a fixed tunnel IP.
|
||||
- Firewall -> Rules -> OpenVPN: PASS `<Richard tunnel IP>` -> `10.0.30.0/24`; BLOCK `<Richard tunnel IP>` -> `RFC1918`.
|
||||
- If the VPN server is shared, use the CSO + per-tunnel-IP rules (do NOT widen the server's global Local Networks). If Vertical-only, may edit the server in place.
|
||||
6. ~~**OpenVPN — reach desktop on VOICE, scoped to voice only**~~ — **NOT NEEDED (2026-06-17).** Vertical uses **LogMeIn** (outbound agent), not the pfSense OpenVPN, to reach the desktop. The desktop's internet egress on VOICE (rule (d)) is all LogMeIn requires. No CSO, no cert CN, no OpenVPN firewall rules for Vertical. (Howard's own OpenVPN access is unaffected.)
|
||||
|
||||
## PART B — UniFi (UOS controller)
|
||||
|
||||
@@ -82,11 +85,8 @@ Probed from CS-SERVER (`192.168.2.254`, same LAN segment) — read-only.
|
||||
1. Build everything with no live impact: pfSense VLAN/DHCP/firewall, OpenVPN CSO+rules, UniFi network, create the voice PPSK.
|
||||
2. **AudioCodes:** flip USW-16-PoE ports 1-8 -> VOICE. Re-DHCP + re-register (brief blip).
|
||||
3. **Poly:** re-key to voice PPSK. Roam onto VOICE.
|
||||
4. **Desktop (coordinated with Vertical — static, no login):**
|
||||
- Confirm OpenVPN pushes `10.0.30.0/24` to Richard.
|
||||
- Remote path: Vertical sets NIC -> DHCP FIRST (pulls a temp main-LAN lease, stays reachable) -> confirm reconnect -> THEN flip port 16 -> VOICE -> desktop renews to `10.0.30.10` -> Vertical reconnects via VPN.
|
||||
- Onsite path (cleaner): set DHCP + flip port together at the keyboard.
|
||||
5. Hand Richard `10.0.30.10`; confirm VPN reach + phone reach from the desktop.
|
||||
4. **Desktop (zero-touch — DHCP, LogMeIn):** flip port 16 -> VOICE. Desktop re-DHCPs to `10.0.30.10` (its reservation). LogMeIn re-homes over internet egress automatically (no NIC change, no Vertical action needed). Brief blip only.
|
||||
5. Confirm with Richard: LogMeIn reconnects to the desktop, and from the desktop he can reach the phones on `10.0.30.x`.
|
||||
|
||||
## Validation
|
||||
- VOICE DHCP leases show phones on `10.0.30.x`; desktop on `10.0.30.10`.
|
||||
@@ -100,12 +100,13 @@ Revert UniFi port native VLAN (1-8, 16) + the PPSK key to prior networks; AudioC
|
||||
|
||||
---
|
||||
|
||||
## Open items (pending Richard)
|
||||
- Confirm phones register to **cloud/hosted PBX** (recon says yes) -> if so, Part A step 5b pinhole is skipped.
|
||||
- Confirm desktop is **static** (asked in the email) and arrange NIC change or temp access at cutover.
|
||||
- Get **Richard's VPN certificate CN** for the scoped Client-Specific-Override.
|
||||
- Confirm pfSense **DHCP backend** (ISC vs Kea) when connected (reservations placed out-of-pool either way).
|
||||
- Schedule the maintenance window.
|
||||
## Open items
|
||||
- [RESOLVED 2026-06-17] Desktop is **DHCP** (verified on pfSense) -> zero-touch cutover.
|
||||
- [RESOLVED 2026-06-17] Remote access is **LogMeIn**, not OpenVPN -> step 6 dropped; only internet egress needed.
|
||||
- [RESOLVED 2026-06-17] DHCP backend = **ISC dhcpd** (Kea dormant) -> out-of-pool reservations safe.
|
||||
- [OPEN] Confirm phones register to **cloud/hosted PBX** (recon says yes) -> if so, Part A step 5b pinhole stays skipped. Low risk: if a phone fails to register after cutover, add the pinhole.
|
||||
- [OPEN] **Schedule the maintenance window** for the live port flips (AudioCodes ports 1-8 = brief blip; port 16 desktop = brief blip).
|
||||
- [OPEN] **Poly re-key method**: 22 WiFi phones must be pointed at the new voice PPSK — by hand per phone, or via Vertical provisioning. Richard offered to help during the transition; bulk provisioning by Vertical is the clean path.
|
||||
|
||||
## Appendix — device inventory (MACs)
|
||||
**AudioCodes (wired, USW-16-PoE):**
|
||||
|
||||
@@ -74,3 +74,37 @@ quirk, not a real fault. No action needed unless WAN2 misbehaves.
|
||||
|
||||
**Conclusion:** gateway/DHCP/DNS/WAN are not bottlenecking the wireless. The 2.4 GHz remediation
|
||||
(power-down + coverage-redundancy disables) remains the correct and sole fix for the client-experience tail.
|
||||
|
||||
## Daytime re-check (2026-06-17, ~09:33, loaded network)
|
||||
|
||||
Post-remediation loaded-network measurement (overnight 6/17: 24 of 76 2.4 radios disabled, 42 set to Low
|
||||
~6 dBm; Floors 5/6 + mesh untouched). Fleet healthy: 77 adopted / 2 disconnected (same known 108 + 1) --
|
||||
**no AP went offline.**
|
||||
|
||||
**Active-radio-only snapshot (09:33, excludes the 24 disabled):** cu_total 67%, cu_interf 48%, clients 105
|
||||
(vs pre-change active cu_total 77% / cu_interf 64%).
|
||||
|
||||
**Time-of-day-controlled hourly (this AM vs same hours yesterday @ full power):**
|
||||
| 2.4 site-wide AM | Yesterday (full) | Today (post) |
|
||||
|---|---|---|
|
||||
| cu_total | 79% | 44% |
|
||||
| cu_interf | 66% | 32% |
|
||||
| retry% | 17.0% | 23.4% |
|
||||
| satisfaction | 39 | 30 |
|
||||
| sta/radio | 2.32 | 2.21 |
|
||||
|
||||
**Mixed result -- read honestly:**
|
||||
- WIN: 2.4 interference/airtime is clearly down (fewer contending transmitters + smaller cells). On the
|
||||
active radios, cu_interf ~64% -> ~48% (snapshot) / 66% -> 32% (morning hourly avg, fewer radios).
|
||||
- CONCERN: **retry rose (17.0 -> 23.4%) and satisfaction fell (39 -> 30)** time-of-day-controlled. Likely
|
||||
OVER-THINNING: Low = ~6 dBm is a 17 dB cut from auto (~23), and with 24 radios also disabled some edge
|
||||
2.4 clients now reach a farther/weaker AP -> more retransmits, lower satisfaction. (Partly composition:
|
||||
fewer 2.4 clients today, so the remaining tail may be the stubborn legacy/far devices.)
|
||||
|
||||
**RECOMMENDATION (needs Howard's go -- this re-check is read-only):**
|
||||
1. Bump the KEPT 2.4 radios from Low -> **Medium** (~12-15 dBm): restores client signal while keeping cells
|
||||
smaller than full power. `apply-radio cascades ng power medium --zone ...` per floor, then re-measure.
|
||||
2. Do NOT expand disables further; consider re-enabling a specific radio if a dead zone/complaint appears.
|
||||
3. Re-measure retry/satisfaction after the Low->Medium bump (same time-of-day) to confirm recovery.
|
||||
The interference goal is met; the lever now is finding the power floor that keeps cells tight WITHOUT
|
||||
starving edge clients. Medium is the likely sweet spot vs the aggressive Low.
|
||||
|
||||
Reference in New Issue
Block a user