---
name: project_cascades_vlan20_migration_routing
description: Cascades CSC ENT->VLAN20 migration — pfSense WAN_Group policy-route breaks LAN<->VLAN20; fix + printer-migration mechanics
metadata:
  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.<x>: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]].
