claudetools/clients/valleywide/session-logs/2026-06/2026-06-15-mike-vwp-files-single-home-scan-fix.md

User

• User: Mike Swanson (mike)
• Machine: GURU-5070
• Role: admin

Session Summary

Fixed Valley Wide Plastering's copier/scanner (Brother MFC-L3780CDW) scan-to-folder, which had stopped working after the 2026-06-13 G: file-share migration. Root cause: VWP-FILES was multi-homed (192.168.0.20 on VLAN 2 + 172.16.9.132 on the new net), and a Windows host realistically supports one default gateway — only the .132 NIC had one (172.16.9.1). So cross-VLAN traffic to .20 arrived on the .20 NIC but the reply egressed via the .132 default-gateway path, and the UDM dropped the asymmetric return. .20 was therefore unreachable from any other VLAN (proved: .20 was silent from the VPN pool while .25/.132 answered). The copier reaches \192.168.0.20\<share> across a VLAN boundary, so it broke.

The previously-documented "VWP-FILES Dual-NIC / asymmetric-routing / same-VLAN-only" note was a flawed workaround, not a real constraint — the UDM routes every VLAN natively (Mike's correction). Fix: single-home VWP-FILES on .20 and drop .132.

What was done

Diagnostics (read-only): from ADSRVR (a VLAN-2 server) confirmed every VLAN was reachable, SMB tcp/445 up on .20, the scanner AD account enabled/unlocked, and all 19 shares present (\.20\SCANS + per-person scan shares). Confirmed the real VLAN-2 gateway is 192.168.0.1 (ADSRVR's gateway) — the wiki said 172.16.9.1, which was wrong.

Attempt 1 (in-guest via RMM): set .20 gw 192.168.0.1 + DNS, disabled .132. Disabling the NIC dropped the agent's own connection -> command came back interrupted, script killed before confirming success, and the 7-minute auto-rollback task fired and re-enabled .132 (box healthy, but back to dual-homed). Lesson: an in-guest NIC change self-interrupts the RMM agent.

Final fix (host-side, per Mike's Hyper-V suggestion): via the VWP-HYPERV1 RMM agent, Disconnect-VMNetworkAdapter on VWP-FILES's .132 vNIC (Network Adapter, MAC 00155D090501), keeping the .20 vNIC (OldNet-VLAN2, MAC 00155D090502). Completed cleanly (the host's RMM connection is unaffected by the guest's NIC change). Then cleaned the guest's stale .132 IP/route and ipconfig /registerdns.

Verified: .20 now reachable cross-subnet from the VPN (was failing pre-fix); single default route .20 -> 192.168.0.1; VWP-FILES resolves to .20 only; 19 shares intact.

Key facts / corrections

• VWP-FILES is now single-homed: 192.168.0.20, gw 192.168.0.1, DNS 172.16.9.2 + 192.168.0.25.
• The .132 vNIC is DISCONNECTED at the Hyper-V host (reversible), not removed.
• Old Net (VLAN 2, 192.168.0.0/24) gateway is 192.168.0.1 — the wiki's 172.16.9.1 was wrong.
• Scanner = Brother MFC-L3780CDW (vault clients/vwp/brother-mfc-l3780cdw); scans to \192.168.0.20\<share> (shares map under G:\SCANS\...).
• RMM agents: VWP-FILES 8e02fbbc, VWP-HYPERV1 bdc3e142.

Gotchas learned

• In-guest RMM NIC changes self-interrupt (the change drops the agent connection). For VM NIC changes, drive it host-side (Disconnect-VMNetworkAdapter / PowerShell Direct) so the host connection survives. Keep an auto-rollback timer either way.
• /rmm hostname match "hyperv" hit DF-HYPERV-B (Dataforth) first — must resolve VWP-HYPERV1 explicitly. The script's guard aborted safely on the wrong host (no changes).

Pending / Incomplete

• Have someone confirm an actual scan from the Brother copier (only thing not driveable remotely).
• Decide whether to fully remove the disconnected .132 vNIC or leave it (currently left, reversible).
• Harmless leftover on VWP-FILES: C:\Windows\Temp\vwp-net-rollback.ps1 (from attempt 1).

Reference

• VWP-FILES: single-homed 192.168.0.20, gw 192.168.0.1. RMM agent 8e02fbbc.
• VWP-HYPERV1: 172.16.9.184, RMM agent bdc3e142. VWP-FILES vNICs: Network Adapter(.132, disconnected) / OldNet-VLAN2(.20).