claudetools/.claude/memory/project_cascades_vlan20_migration_routing.md

name, description, metadata

name	description	metadata
project_cascades_vlan20_migration_routing	Cascades CSC ENT->VLAN20 migration — pfSense WAN_Group policy-route breaks LAN<->VLAN20; fix + printer-migration mechanics	type project

Cascades is migrating staff machines + printers off the flat old LAN (192.168.0.0/22, "CSC ENT") onto the isolated Staff VLAN 20 (10.0.20.0/24, gw 10.0.20.1) ("CSCNET"). Printers are being re-IP'd to 10.0.20.x (static) and re-shared on the CS-SERVER print server.

PROGRESS (live-reconciled 2026-07-01): MACHINES are essentially done — 22 online hosts on VLAN 20; only CS-SERVER (stays by design) + ~6 stragglers (ASSISTMAN-PC, CascadesProxess, Laptop2, NurseAssist, 2 roaming laptops) remain on 192.168.x. PRINTERS lag — only 4 of 15 CS-SERVER shares repointed to 10.0.20.x (FrontDesk .221, BusinessOffice .220, LifeEnrichment .94, MCReception .78); 11 shares still on old-LAN IPs (MCMedTech still stale 192.168.2.53 though target 10.0.20.74 is live+reachable). GPO still NOT fleet-live (silent new-driver-install gap open: reboot vs pre-stage drivers). MEMCARE-STATION rename staged but not yet applied. Full live inventory (all shares/ports/machines): clients/cascades-tucson/docs/printer-gpo-map.md.

Key operational facts learned 2026-06-30 (Howard, front-desk ET-5800 + Life Enrichment Canon MF741CDW):

pfSense gotcha (the big one): CS-SERVER (on the old LAN) could not reach ANY VLAN 20 printer (.221/.220/.94/.78:9100) even though it pinged the VLAN20 gateway 10.0.20.1. Root cause was NOT a block — the LAN "Default allow LAN to any" rule has Gateway = WAN_Group (dual-WAN policy routing), so LAN->internal-VLAN traffic gets shoved out the WAN and dies. Fix = a pass rule at the TOP of the LAN interface (Firewall/Rules/LAN), Source = CS-SERVER 192.168.2.248, Dest = 10.0.20.0/24, protocol any, Gateway = default (do NOT set WAN). This bypasses the policy route so internal traffic routes normally. Scoped to the server's source IP => residents (own /28 VLANs) + guests (VLAN 50) can't match it (rule is on the LAN interface, sourced from the server only). This also un-broke the already-migrated Business Office/Life Enrichment/MC Reception shares. VLAN20->server (SMB) was already fine.

pfSense SSH from the VPN is BLOCKED (tcp/22 dropped; GUI 443 open). The unifi-wifi skill's pfsense-ssh.sh therefore returns empty (it sends ssh stderr to /dev/null). Did the rule via the GUI instead. To use the skill remotely later, add an OpenVPN-side allow for 22.

Printer migration mechanics:

• CS-SERVER side: repoint the share's port to TCP_10.0.20.:9100 (Set-Printer -PortName), drop the old 192.168.2.x port; keep the same ShareName so client mappings survive.
• Client side: mapping \\CS-SERVER\<share> as a standard domain user triggers a PrintNightmare elevation prompt (HRESULT 0x800702e4) EVEN when the driver is already local — see feedback_rmm_printer_elevation / errorlog. Promptless options: GPO printer deployment (they already do this for caregivers — the scalable answer), or push as SYSTEM via rundll32 printui.dll,PrintUIEntry /ga /n"\\CS-SERVER\<share>" (per-machine, appears at the user's NEXT logon), or set Point-and-Print "Approved server = CS-SERVER" so user- context maps are promptless+immediate.
• Old room-named shares (e.g. 1F-132-RecRoom-Canon) were renamed on the server during migration, leaving ORPHANED per-user client mappings; a spooler restart auto-drops them.
• Build UNC paths in RMM PowerShell with [char]92, not literal \\ (jq/agent pipeline mangles literal backslashes — feedback_windows_quote_stripping).

Point-and-Print is the REAL promptless fix (proven 2026-06-30 on the LE machines). The 0x800702e4 prompt AND the /ga per-machine path silently failing at logon (PrintService event 513, error 0xBCB) are BOTH the same default RestrictDriverInstallationToAdministrators (ON when unset) blocking the standard user from pulling the driver. We're domain admin, but the end user isn't — so apply admin rights via the Point-and-Print policy: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers RestrictDriverInstallationToAdministrators=0

• subkey PointAndPrint Restricted=1,TrustedServers=1,ServerList=CS-SERVER,InForest=0, NoWarningNoElevationOnInstall=1,UpdatePromptSettings=2 (scopes silent install to CS-SERVER only). After that, WScript.Network.AddWindowsPrinterConnection in the user session is promptless+immediate. Correct durable fix = put this in a computer GPO fleet-wide (the caregiver machines already have it; that's why their printer GPO works), then deploy printers via GPO. Existing GPOs: CSC - Life Enrichment Printers, CSC - Printer Deployment, CSC - Caregiver Workstation, CSC - Reception Workstation Policy (the LE one likely still pushes the OLD share name — repoint it to the new share).

Driver/PDL trap — Canon MF741/743 = UFR II ONLY (not PCL). The rebuilt LifeEnrichment share was created with Canon Generic Plus PCL6; the MF741 can't parse PCL → spools OK, nothing prints, panel shows Error #822 (unsupported/corrupt data). Fix = use the UFR II driver (Canon Generic Plus UFR II V250, INF cnlb0ma64.inf). CS-SERVER only had PCL6/PS3/XPS staged; pulled UFR II from a client's DriverStore (C:\Windows\System32\DriverStore\ FileRepository\cnlb0ma64.inf_amd64_*) using the vaulted cs-server sysadmin domain-admin cred. Transfer direction matters: CS-SERVER (192.168.2.x) CANNOT reach a client's C$ (client host-firewall scopes File/Print sharing to LocalSubnet, and CS-SERVER is off-subnet) -> have the CLIENT push to \\CS-SERVER\C$ instead (client->server SMB works). Then pnputil /add-driver <inf> /install, Add-PrinterDriver -Name "<exact INF model name>", Set-Printer -DriverName. Get the exact driver name from the INF's quoted strings, not a guess. When the server driver changes, refresh each client connection (Remove+AddWindowsPrinterConnection) so it drops the stale cached PCL6 driver.

Related: wiki clients/cascades-tucson (network/VLANs), project-cascades-migration-plan.