---
type: client
name: goldstein
display_name: Goldstein (Sheldon Goldstein)
last_compiled: 2026-07-10
compiled_by: HOWARD/claude-main + BEAST/discord-bot (merged 2026-07-10)
sources:
  - 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 #32490, #32384)
  - 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)
backlinks: []
---

# 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)*
