azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
285687d48d968b7f7e3ef3d03b7f22e6123d837f
claudetools/wiki/clients/goldstein.md
Mike Swanson 285687d48d sync: auto-sync from GURU-BEAST-ROG at 2026-07-10 17:45:57 
Author: Mike Swanson
Machine: GURU-BEAST-ROG
Timestamp: 2026-07-10 17:45:57
2026-07-10 17:48:58 -07:00

13 KiB
Raw Blame History

type, name, display_name, last_compiled, compiled_by, sources, backlinks
type name display_name last_compiled compiled_by sources backlinks
client goldstein Goldstein (Sheldon Goldstein) 2026-07-10 HOWARD/claude-main + BEAST/discord-bot (merged 2026-07-10)
clients/goldstein/session-logs/2026-07/2026-07-06-howard-dallas-rmm-onboard.md
clients/goldstein/session-logs/2026-07/2026-07-07-howard-dallas-rdp-pro-upgrade.md
clients/goldstein/onboarding-baselines/DALLAS-20260706T233936.md
clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md
Live UniFi Site Manager + GuruRMM investigation 2026-07-10 (tickets
clients/goldstein/session-logs/2026-07/2026-07-10-bot-mike-asus2024-dallas-rdp-local-account.md
Discord thread 1525291727911653530 (2026-07-10, Mike — ASUS-2024 RDP + Profwiz local account)

Goldstein (Sheldon Goldstein)

Law firm (lawyersdallas.com) with two physical locations — Dallas, TX (Michelle) and Tucson, AZ / "Armory Park" (Sheldon) — joined by a UniFi Site Magic site-to-site VPN.

Profile

  • Contract type: Break-fix / T&M (Syncro prepay_hours = 0). Small monthly recurring invoice (~$59.30) plus occasional labor at $150/hr remote.
  • Key contacts: Michelle Goldstein — 972-814-5677 (Dallas); Sheldon Goldstein — sheldon@lawyersdallas.com (Tucson / Armory Park).
  • Billing: $150/hr remote (verify onsite/emergency in Syncro). No prepaid block.
  • Syncro customer ID: 25307933

Network & Remote Access ← READ THIS FIRST for any remote/VPN work

UniFi gateways (both in OUR ui.com account — "owner" consoles)

Both sites run a UCG-Ultra (model UDRULT, UniFi Network 10.4.57). Reachable remotely with no LAN/VPN via the UniFi Site Manager cloud API + connector proxy.

Console (ui.com) WAN IP ISP LAN Gateway Console ID
CGU-Goldstein Tucson 98.225.73.165 Comcast (Pima/Tucson) 10.1.10.0/24 10.1.10.1 0CEA146890BF000000000885E5160000000008FA3AD6000000006741FA51:285001334
CGU-Goldstein Dallas 99.127.21.4 AT&T 192.168.1.0/24 192.168.1.1 0CEA1456463900000000087729C50000000008EAA14D0000000067282B45:989250246
  • Both have dual-WAN hardware but Internet 2 is disabled on each.
  • API access: key in vault services/unifi-site-manager (credentials.api_key). Reads via unifi-wifi skill gw-sitemanager.sh (fleet|sites|find|net <console> raw <path>). Gotcha: the skill's net … raw truncates output at 5 KB, so full networkconf (has the OpenVPN cert) must be read directly through the connector: curl -H "X-API-KEY: $KEY" https://api.ui.com/v1/connector/consoles/<ID>/proxy/network/api/s/default/rest/<path> (e.g. rest/networkconf, rest/setting/<key>, rest/routing, rest/account). Writes through the connector DO work (verified) but do gateway config in the UI, not raw API.

Site Magic (auto site-to-site VPN) — LAN-to-LAN ONLY, and it's LOCKED

  • WireGuard-based auto-mesh between the two consoles (magic_site_to_site_vpn, iface wgsts1000). Enabled, healthy, verified BOTH directions (Tucson↔Dallas).
  • Advertises only the two corporate LANs: Tucson shares 10.1.10.0/24, Dallas shares 192.168.1.0/24. It is attr_no_edit / attr_no_delete (auto-managed) — you cannot add networks to it (e.g. an OpenVPN client pool) and there are no static routes.
  • CONSEQUENCE (important): a device only reaches the other site via Site Magic when it is on one of those two LAN subnets. Traffic sourced from any other subnet (like the OpenVPN pool 192.168.2.0/24) is not carried across the mesh. This is why a single offsite VPN connection cannot reach both sites — see the playbook below.

OpenVPN remote-user servers (one per gateway)

  • Both gateways run a native UniFi OpenVPN remote-user server: proto tcp, port 1194, on the WAN. Client pool 192.168.2.0/24 on BOTH (identical — fine because a client only connects to one at a time).
  • Auth = RADIUS (each gateway's built-in RADIUS server; shared secret). RADIUS users Michelle and Sheldon exist on BOTH gateways (each UCG has its own RADIUS server, so users must be created on both). Username is Michelle (not "michell").
  • All secrets + both client .ovpn profiles → vault clients/goldstein/openvpn-remote-access.sops.yaml (radius_secret, tucson/dallas endpoints, *_ovpn_b64, michelle_/sheldon_vpn_username/password).
  • The UniFi-exported .ovpn ships full-tunnel (redirect-gateway def1) + comp-lzo. For a clean split-tunnel client on OpenVPN 2.6: drop redirect-gateway, change comp-lzo → compress lzo + allow-compression yes, add route-nopull + explicit route lines, and point auth-user-pass at a creds file. (Defender flags the .ovpn — its embedded key — so add a Defender exclusion for the OpenVPN config folder before re-enabling Defender.)

Remote-access playbook (how ASUS-2024 reaches DALLAS + DalRes10)

ASUS-2024 is a roaming laptop (Michelle, user miche) that moves between the Tucson office and offsite. It needs to RDP into DALLAS (192.168.1.226) and DalRes10 (10.1.10.170).

  • At the Tucson office → OpenVPN OFF. Put the laptop on the UniFi "Goldstein" WiFi (10.1.10.x) and Site Magic gives it both machines: DalRes10 local, DALLAS over the mesh. GOTCHA: the office also has a separate Cox network broadcast as SSID Gold-Scop (192.168.0.0/24, gw 192.168.0.1) — that is NOT the UniFi LAN and NOT on Site Magic. A laptop on Gold-Scop can reach neither site's internal machines. Must be on the UniFi WiFi.
  • Offsite → OpenVPN ON, TWO profiles (one connection can't reach both — Site Magic won't carry the VPN pool): connect the Dallas profile to RDP DALLAS; connect the Tucson profile to RDP DalRes10. Pick the profile for the machine you want.
  • RDP shortcuts already on ASUS: Tucson Computer.rdp → 10.1.10.170 (DalRes10), Dallas Computer.rdp → 192.168.1.226 (DALLAS).

DO NOT: machine-level WireGuard tunnels

Leftover machine-level WireGuard configs exist (WireGuardServer1-Client1 on ASUS-2024; a tunnel on DalRes10) from a prior June attempt. They are full-tunnel and dangerous — activating the one on DalRes10 (2026-07-10) captured its own routing and took it completely offline (no remote path; requires deactivating WireGuard at the console). Do NOT activate these; they're being removed in favour of OpenVPN. Teleport was disabled on the Tucson UCG (2026-07-10) as part of the move to OpenVPN.

Infrastructure

GuruRMM

  • Client: Goldstein — 7eed26be-4126-40a5-8414-3c0c28b9d182
  • Sites: Dallas — code SILVER-PEAK-3739, id 653b7e39-5e5e-4b93-b135-c70fc12ececa · Tucson — code RED-LION-9255, id 4526ef0e-31d6-48f1-8df4-40d3a16519c1
  • Note: RMM "site" tags don't always match physical location — ASUS-2024 is tagged Dallas but physically roams (often on Cox in AZ).

Endpoints

Host Site IP (RDP target) Role / Notes
DALLAS Dallas 192.168.1.226 (Wi-Fi) Michelle's Lenovo Yoga Slim 7, Win 11 Pro for Workstations (upgraded from Home 2026-07-07, MAK). RDP host (fDenyTS=0, NLA, TermService Auto). Public 99.127.21.4. Modern-Standby — kept AC-no-sleep. The machine staff RDP into. Login account: local Sheldon — ProfWiz-migrated from Michelle's Microsoft account (Mike, 2026-07-10) because the MSA login was BLOCKING RDP. Password in vault clients/goldstein/windows-sheldon-local, set to never expire. Agent 36c7bbc8-504f-4b4a-8995-3b3e5cdc0f02; SC 29c62473-a5cb-4e94-a190-c91f05031809.
DalRes10 Tucson 10.1.10.170 (Wi-Fi) Sheldon's desktop. RDP host (fDenyTS=0, NLA) — but TermService StartType = Manual (won't auto-start RDP after reboot). Target IP is on Wi-Fi (also Ethernet 10.10.1.149 on a different segment) so RDP reachability tracks Wi-Fi. Agent 81cde315-013b-4acd-80d7-5ec2b9b5f084.
ASUS-2024 Dallas (tag) roams — Cox 192.168.0.200 when on Gold-Scop; seen in Phoenix 2026-07-10 Roaming laptop (Michelle, user miche). Has the OpenVPN client + RDP shortcuts to both targets, plus RDP DALLAS.rdp on the Public Desktop (pushed via RMM 2026-07-10). Agent f50b17c1-a711-4e80-89c2-03cb630f5622; SC cfddaed7-b6b9-463c-b210-384dec88e0f8.
GS-Backup Tucson — Tucson backup/file-share box. Local account Sheldon added 2026-07-10 (matches the DALLAS account so SMB shares auth seamlessly; same vaulted password, never expires). Agent 4f52ef22-89ae-4124-a2b4-d339aaf42f53.

Access

  • UniFi: ui.com Site Manager (both Goldstein consoles are "owner") — see Network section.
  • ScreenConnect: DALLAS 29c62473-…, DalRes10 a8b53a73-ff0e-42c9-b51f-4ff71aff45f7, ASUS-2024 cfddaed7-…, GS-Backup 75f4ee70-… (all Company=Goldstein).
  • GuruRMM install (Dallas site): https://rmm.azcomputerguru.com/install/SILVER-PEAK-3739
  • RDP into DALLAS: local account DALLAS\Sheldon (password never expires) — creds in vault. Works from ASUS-2024 offsite via the Dallas OpenVPN profile, and from the Tucson LAN over Site Magic.
  • Vault:
    • clients/goldstein/windows-sheldon-local.sops.yaml — local Sheldon account on DALLAS + GS-Backup
    • clients/goldstein/openvpn-remote-access.sops.yaml — OpenVPN/RADIUS (Tucson + Dallas UCG)

Patterns & Known Issues

  • Multi-site, one Syncro customer — Dallas (TX) + Tucson (Armory Park). New endpoints must land in the correct GuruRMM site (Dallas → SILVER-PEAK-3739).
  • Site Magic bridges only the two LANs and is locked — cross-site works for LAN devices, NOT for VPN-pool clients. Offsite remote access = two OpenVPN profiles (Dallas + Tucson).
  • Gold-Scop WiFi ≠ UniFi LAN — it's a separate Cox line (192.168.0.x); a device on it can't reach either site's internal machines. Use the UniFi "Goldstein" WiFi (10.1.10.x) at the office.
  • DALLAS is Modern-Standby — kept AC-no-sleep + lid-does-nothing so it stays RDP-reachable. RDP into DALLAS is single-session (signs the local user out).
  • DalRes10 target IP is on Wi-Fi and TermService is Manual — RDP can vanish if Wi-Fi drops or after a reboot until the service is started.
  • No backup agent detected on DALLAS (2026-07-06) — confirm cloud/local backup need.
  • Microsoft-account login blocked RDP on DALLAS — RDP/NLA against an MSA-backed account (Hello PIN, no cached password) failed to authenticate. Fixed by ProfWiz-migrating the profile to local account Sheldon (same profile, local auth; vaulted never-expiring password — Mike, 2026-07-10). A matching Sheldon account was created on GS-Backup so its SMB shares authenticate with the same credentials. Pattern: for RDP hosts, prefer a local account over a Microsoft/Azure-AD account. (A registry fix DevicePasswordLessBuildVersion=0 was also applied to DALLAS the same day while pursuing the MSA-password route — harmless, superseded.)

Active Work

No open tickets in Syncro as of 2026-07-10 (#32384 "Remote - Issues with remote access" is Resolved/invoiced). Break-fix, no prepaid block. Follow-ups below are open work, not Syncro tickets.

  • DALLAS offsite RDP via OpenVPN: DONE — ASUS-2024 → Dallas profile → RDP DALLAS works.
  • DalRes10: back online (WireGuard deactivated onsite 2026-07-10). Howard removing WireGuard; then set its TermService → Automatic (RDP survives reboot).
  • Import the Tucson OpenVPN profile on ASUS-2024 (98.225.73.165, split-tunnel) so Michelle can RDP DalRes10 offsite — Dallas profile → DALLAS, Tucson profile → DalRes10.
  • OpenVPN 2.6.14 installed on ASUS-2024; Defender re-enabled with OpenVPN-folder exclusions; Teleport disabled on Tucson UCG.
  • Billing: OpenVPN remote-access work (2026-07-10) not yet billed — confirm with Mike.

History Highlights

  • 2026-07-10 — DALLAS RDP fix completed: the machine was on a Microsoft account which blocked RDP; Mike ProfWiz-migrated it to local account Sheldon (never-expiring password, vaulted) and created a matching Sheldon account on GS-Backup for SMB share access. Earlier same day the bot set DevicePasswordLessBuildVersion=0 on DALLAS (superseded), verified ASUS-2024 → DALLAS 3389 over OpenVPN from Phoenix, and pushed RDP DALLAS.rdp to ASUS-2024's Public Desktop.
  • 2026-07-10 — Stood up OpenVPN remote access (both UCGs, RADIUS, users Michelle/Sheldon); mapped the full UniFi/Site-Magic topology; confirmed Site Magic is LAN-only + locked; DALLAS offsite RDP working; DalRes10 taken offline by a stray WireGuard tunnel (pending console fix). Ticket #32384.
  • 2026-07-07 — Enabled Tucson→Dallas RDP: DALLAS Home → Pro → Pro-for-Workstations (MAK), RDP enabled, verified from DalRes10 over the VPN, RDP DALLAS icons on Tucson PCs. #32490 Invoiced (1.0h, $150, invoice 1650967814).
  • 2026-07-06 — Onboarded DALLAS to remote management (ScreenConnect + GuruRMM, AMBER diag). #32490.
  • 2026-06 — Prior remote-access attempt (#32384): Teleport/WireGuard tried, hit route + login issues; Mike reset the Site Magic VPN to restore access at the time.

Backlinks

(none yet)

Reference in New Issue View Git Blame Copy Permalink