3.4 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| project_cascades_network_segments | Cascades of Tucson network segments + the CSC-ENT Wi-Fi SMB block that stalls NAS->CS-SERVER user migration |
|
Cascades of Tucson NAS->CS-SERVER share migration — network reality discovered 2026-06-25.
CS-SERVER (DC, RMM agent, Synology Drive sync target): IPs 192.168.2.248 (Ethernet) and
192.168.2.254 (Hyper-V vSwitch), both /22 = 192.168.0.0/22 (covers .0–.3.255).
Domain CASCADES / cascades.local. SMB healthy — serves 13+ live sessions; shares under
D:\Shares\<name> (Server, Management, Activities, Sales, etc.). Firewall SMB-In = Allow/Any.
Working SMB clients live on 10.0.20.x (routed, gw 10.0.20.1) and 192.168.3.x (on-link
in the /22). Wi-Fi SSID for corporate = CSCNet.
Two Wi-Fi SSIDs (same AP family): CSC ENT = 192.168.2.0/24, gw 192.168.0.1, WPA2-PSK
(old NAS-side); CSCNet = 10.0.20.0/24, gw 10.0.20.1, WPA3-SAE (newer corporate). DNS =
pfSense 192.168.0.1. CSCNet PSK + CSC ENT PSK vaulted (clients/cascades-tucson/wifi-cscnet.sops.yaml,
wifi-csc-ent.sops.yaml).
CORRECTION (don't trust the first theory): the SMB problem is NOT CSC-ENT-vs-CSCNet. Verified
2026-06-26: fresh SMB connections to \\cs-server\<share> fail with System error 67
(BAD_NETWORK_NAME), even IPC$, from CSC ENT AND CSCNet alike (Meredith on CSC ENT, Crystal +
Karen on CSCNet all hit it). Only pre-existing persistent mapped drives work, and even those are
intermittent (Meredith's Y: \\cs-server\Server read True then False minutes later). Lower layers
are fine everywhere (ping, nbtstat=CS-SERVER, TCP 445/139). So it's a CS-SERVER-side SMB
instability, not the client network.
Root-cause leads (CS-SERVER): Get-SmbServerConfiguration throws "Data of this type is not
supported" (degraded SMB config subsystem); SMB multichannel advertises multiple interfaces —
192.168.2.248 (Ethernet), 192.168.2.254 (Hyper-V vSwitch), and IPv6 ULAs (fde4::…,fd8f::…).
Clients negotiating channels to unreachable interfaces is the prime suspect for flaky/failed new
sessions. SMB signing required (it's a DC). Likely fixes (NEED approval, prod DC, 13 live sessions):
disable SMB multichannel / unbind File&Printer sharing from .254+IPv6 so it serves only on .248;
and/or restart LanmanServer (or reboot) to rebuild the degraded config.
Two more migration blockers found: (1) CSCNet is WPA3-SAE — older adapters (e.g. Intel AC 3165
on Meredith's ASSISTMAN-PC) cannot join it, so "move everyone to CSCNet" is blocked by hardware.
(2) Security smell: workstations are WORKGROUP (local logins) and reach CS-SERVER by storing a
DOMAIN credential — Meredith's PC stores cmdkey cs-server→administrator (her Y:/X:/E: are mapped as
domain admin). Shares Server/Management = share ACL Authenticated Users:Full (NTFS gates real
access). Fix: stop storing admin creds on user PCs; scope shares to groups.
Karen Rossini case (DESKTOP-LPOPV30, WORKGROUP, dual Wi-Fi): CASCADES\karen.rossini reset+vaulted
(clients/cascades-tucson/karen-rossini.sops.yaml), added to SG-IT-RW, CS-SERVER cmdkey staged.
She doesn't really use the Server folder (per Howard) so deprioritized. ALDocs is in
\\CS-SERVER\Server\ALDocs. Repoint tooling = drive-map skill (but blocked by the CS-SERVER SMB
instability above — fix that first).