From 273eb150c85c98d0e517bc2bd205b0865180e9b6 Mon Sep 17 00:00:00 2001 From: Howard Enos Date: Fri, 10 Jul 2026 17:21:06 -0700 Subject: [PATCH] sync: auto-sync from HOWARD-HOME at 2026-07-10 17:20:37 Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-07-10 17:20:37 --- ...-howard-openvpn-remote-access-sitemagic.md | 175 ++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md diff --git a/clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md b/clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md new file mode 100644 index 00000000..7653dc26 --- /dev/null +++ b/clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md @@ -0,0 +1,175 @@ +# Session Log — Goldstein: OpenVPN remote access + full network topology mapping + +## User +- **User:** Howard Enos (howard) +- **Machine:** Howard-Home +- **Role:** tech + +## Session Summary + +Resumed remote-access work for Goldstein under Syncro ticket #32384 ("Remote - Issues with remote +access"). The stated goal firmed up over the session: the roaming laptop **ASUS-2024** (Michelle, +user `miche`) must be able to RDP into two machines from anywhere — **DALLAS** (192.168.1.226, +Dallas office) and **DalRes10** (10.1.10.170, Tucson office). Began by loading prior context +(#32490 Dallas RDP enablement, the June #32384 attempt) and confirming machine identities. + +Mapped the entire Goldstein network from the UniFi Site Manager cloud API + connector proxy: both +sites run a UCG-Ultra (UDRULT, Network 10.4.57) that we own in our ui.com account. Established that +the Tucson↔Dallas link is a **UniFi Site Magic auto-mesh** (WireGuard-based, `wgsts1000`) that is +auto-managed/locked (`attr_no_edit`/`attr_no_delete`) and bridges **only the two corporate LANs** +(10.1.10.0/24 ↔ 192.168.1.0/24), verified working both directions. Discovered the June "WireGuard" +was actually Teleport (enabled on both gateways) plus leftover machine-level WireGuard tunnels. + +Diagnosed why ASUS couldn't reach the offices: it was on the office's **separate Cox network +(SSID `Gold-Scop`, 192.168.0.0/24)**, which is not the UniFi LAN and not on Site Magic. Mike +directed switching remote access to OpenVPN. Mike disabled Teleport (I confirmed/executed the +Tucson toggle), then set up native UniFi **OpenVPN remote-user servers** on both UCGs (TCP 1194, +RADIUS auth, pool 192.168.2.0/24 on both) and created RADIUS users Michelle + Sheldon on both +gateways. I vaulted the RADIUS secret + both client `.ovpn` profiles + user creds, then deployed a +split-tunnel OpenVPN client to ASUS-2024 (OpenVPN 2.6.14) and proved the tunnel up. Testing showed +the Tucson-anchored connection reached Tucson but not Dallas — the OpenVPN pool doesn't traverse +Site Magic. After pulling the live config (as Mike requested), confirmed this is a hard Site Magic +limitation, so the offsite design landed on **two profiles** (Dallas profile → DALLAS, Tucson +profile → DalRes10), and the office design on **Site Magic with the VPN off (on the UniFi WiFi)**. + +DALLAS offsite RDP was confirmed working (Michelle imported the Dallas profile). DalRes10 had been +knocked fully offline earlier in the session when someone activated its machine-level WireGuard +tunnel (full-tunnel captured its own routing; no remote path — required onsite console +deactivation, which happened ~4pm). Closed out by updating the Goldstein wiki with the complete +topology, and adding Defender exclusions for the OpenVPN config folders + confirming Defender +re-enabled on ASUS-2024. Howard is removing the DalRes10 WireGuard himself. + +## Key Decisions + +- **Switched remote access from Teleport/WireGuard to OpenVPN** (Mike's call). Teleport's June + failures ("steps on routes at home" = subnet overlap; "login credentials incorrect" = Ubiquiti + account / RADIUS) and the machine-level WireGuard tunnels (which took DalRes10 offline) made them + a poor fit for a roaming law-firm laptop. +- **Offsite = two OpenVPN profiles, not one-connection-both.** Pulling the live gateway config + proved UniFi Site Magic is auto-managed/locked and carries only corporate LANs — it will NOT + route the OpenVPN client pool (192.168.2.0/24) across the mesh, and there is no way to add it. + So a single offsite VPN connection cannot reach both sites. Two profiles (connect the one for the + target machine) is the working design; abandoned the earlier "de-conflict pool + advertise across + mesh" idea because Site Magic cannot be extended. +- **Office = Site Magic with VPN off.** A device on the Tucson UniFi LAN (10.1.10.x) already + reaches DalRes10 (local) + DALLAS (mesh). The catch is the laptop must be on the UniFi "Goldstein" + WiFi, not the separate Cox `Gold-Scop` network. +- **Split-tunnel OpenVPN client** (drop `redirect-gateway def1`, `route-nopull` + explicit + `route` lines) so a client can never full-tunnel itself offline the way the WireGuard tunnel did. +- **Used the vault skill for all secrets and referenced vault paths in the log** rather than + committing plaintext (pre-commit guard + vault-skill rule). +- **Did gateway config in the UI (Howard/Mike), not via raw connector writes** — after a + mid-session correction that hand-rolling the UniFi API instead of the skill is wrong; the skill + has no VPN-server command, so the server build was done in the UI. + +## Problems Encountered + +- **DalRes10 taken fully offline by its own WireGuard tunnel.** Activating the machine-level + `WireGuardServer1-Client1`-style tunnel installed routes that captured its network path (RMM + + ScreenConnect both went dark). WireGuard does not time out; a reboot would re-break it (auto-start + service). No remote recovery possible — required onsite console deactivation (~4pm). Resolved by + onsite visit; Howard removing WireGuard. +- **Cross-site VPN routing dead-end.** ASUS on the Tucson OpenVPN pool (192.168.2.2) reached the + Tucson gateway but not DALLAS. Root cause: Site Magic advertises only the LANs and is locked + (`attr_no_edit`), so the pool can't be carried. Both OpenVPN servers also use the same pool + (192.168.2.0/24). Pivoted to the two-profile design. +- **Corrected hand-rolling the UniFi API.** Was reading (and made one write — Teleport disable) via + raw `curl` to the connector instead of the `unifi-wifi` skill. Logged as a correction; skill's + `gw-sitemanager.sh` is the read path, but its `net … raw` truncates at 5 KB, so full networkconf + legitimately needs a direct connector read. +- **Defender ate the OpenVPN `.ovpn`** (embedded private key). Added Defender exclusions for the + OpenVPN config folders; Defender had already auto-re-enabled (tamper protection), confirmed on. +- **DalRes10 cleanup command timed out** (server-side reaper at 120s; the `wireguard + /uninstalltunnelservice` / manager-stop hung). Backed off to a read-only diagnostic; Howard then + opted to remove WireGuard himself. +- **RADIUS username mismatch** — Howard typed "michell"; the actual RADIUS account is `Michelle`. + Corrected the vaulted username to match the gateway. +- **Local `curl`/jq friction** — a `/tmp` path tripped the block-tmp-path hook; a jq filter with a + raw `C:\Program Files` path failed (invalid JSON escapes) — fixed by passing PowerShell via + `jq --arg`, not inline. + +## Configuration Changes + +- **ASUS-2024** — installed OpenVPN Community 2.6.14 (service OpenVPNService/Interactive); deployed + then removed a split-tunnel `goldstein.ovpn` (Howard re-imports via GUI); added Defender + ExclusionPath for `C:\Users\miche\OpenVPN`, `C:\Program Files\OpenVPN\config`, + `C:\Program Files\OpenVPN\config-auto`; created `Dallas Computer.rdp` (→192.168.1.226) on + Michelle's OneDrive Desktop + Public Desktop. +- **CGU-Goldstein Tucson (UCG)** — Teleport disabled (setting `teleport` enabled=false) via + connector write; OpenVPN remote-user server (Mike, UI). Site Magic + Dallas mesh unchanged. +- **CGU-Goldstein Dallas (UCG)** — OpenVPN remote-user server (Mike, UI); RADIUS users + Michelle + Sheldon (Mike, UI). +- **DalRes10** — WireGuard tunnel deactivated at console (onsite); Howard removing WireGuard. +- **Vault** — created `clients/goldstein/openvpn-remote-access.sops.yaml`. +- **Wiki** — rewrote `wiki/clients/goldstein.md` with full network + remote-access topology. +- **Repo** — logged one correction to `errorlog.md` (unifi-wifi hand-rolled API). + +## Credentials & Secrets + +- **All vaulted at `clients/goldstein/openvpn-remote-access.sops.yaml`** (do not duplicate plaintext + here — pre-commit guard + vault rule): + - `credentials.radius_secret` — shared RADIUS secret (same on both UCG built-in RADIUS servers). + - `credentials.tucson_endpoint` = 98.225.73.165:1194 tcp · `credentials.dallas_endpoint` = + 99.127.21.4:1194 tcp. + - `credentials.tucson_ovpn_b64` / `credentials.dallas_ovpn_b64` — full client `.ovpn` (base64; + each embeds a client cert + private key). + - `credentials.michelle_vpn_username` = `Michelle` (NOT "michell") + `..._password`; + `credentials.sheldon_vpn_username` = `Sheldon` + `..._password`; `credentials.vpn_username` + /`vpn_password` = the Michelle primary. +- UniFi Site Manager API key: existing vault `services/unifi-site-manager` (`credentials.api_key`). +- No plaintext secrets committed. + +## Infrastructure & Servers + +- **CGU-Goldstein Tucson** — UCG-Ultra (UDRULT, Net 10.4.57); WAN 98.225.73.165 (Comcast/Pima); + LAN 10.1.10.0/24 (gw 10.1.10.1); dual-WAN (Internet 2 disabled); console id + `0CEA146890BF000000000885E5160000000008FA3AD6000000006741FA51:285001334`. OpenVPN server tcp/1194 + pool 192.168.2.0/24; Teleport now disabled. +- **CGU-Goldstein Dallas** — UCG-Ultra; WAN 99.127.21.4 (AT&T); LAN 192.168.1.0/24 (gw 192.168.1.1); + console id `0CEA1456463900000000087729C50000000008EAA14D0000000067282B45:989250246`. OpenVPN + server tcp/1194 pool 192.168.2.0/24. +- **Site Magic** — `magic_site_to_site_vpn` enabled both sides, iface `wgsts1000`; Tucson advertises + 192.168.1.0/24, Dallas advertises 10.1.10.0/24; auto-managed/locked; no static routes. +- **DALLAS** — 192.168.1.226 (Wi-Fi); Win 11 Pro for Workstations; RDP host (fDenyTS=0, NLA, + TermService Auto); RMM agent 36c7bbc8-504f-4b4a-8995-3b3e5cdc0f02; SC 29c62473-a5cb-4e94-a190-c91f05031809. +- **DalRes10** — 10.1.10.170 (Wi-Fi; also Ethernet 10.10.1.149 on a different segment); RDP host + (fDenyTS=0, NLA); TermService was **Manual** (won't auto-start after reboot — set Auto pending); + RMM agent 81cde315-013b-4acd-80d7-5ec2b9b5f084; SC a8b53a73-ff0e-42c9-b51f-4ff71aff45f7. +- **ASUS-2024** — roaming laptop (user `miche`); on Cox `Gold-Scop` 192.168.0.200/24 (gw 192.168.0.1) + when in office; RMM agent f50b17c1-a711-4e80-89c2-03cb630f5622; SC cfddaed7-b6b9-463c-b210-384dec88e0f8. +- **GS-Backup** — Tucson; RMM agent 4f52ef22-89ae-4124-a2b4-d339aaf42f53. + +## Commands & Outputs + +- UniFi connector read (full networkconf, skill `raw` truncates at 5 KB): + `curl -H "X-API-KEY: $KEY" https://api.ui.com/v1/connector/consoles//proxy/network/api/s/default/rest/|routing|account>` +- Teleport disable (write via connector): `PUT …/rest/setting/teleport/<_id>` `{... enabled:false}` → `{"rc":"ok"}`. +- OpenVPN client verify on ASUS: `Get-Content 'C:\Program Files\OpenVPN\log\goldstein.log'` → + `Initialization Sequence Completed`; VPN IP 192.168.2.2; routes 10.1.10.0/24 + 192.168.1.0/24 added. +- Reachability from ASUS (Tucson-anchored tunnel): `Test-NetConnection 10.1.10.1` ping True; + `Test-NetConnection 192.168.1.226 -Port 3389` TcpTest **False** (cross-site fails via Site Magic). +- Site Magic reverse: DALLAS `Test-NetConnection 10.1.10.1` ping True (mesh healthy both ways). +- Defender: `Add-MpPreference -ExclusionPath …`; `Get-MpComputerStatus` → RealTime/Antivirus/Tamper all True. + +## Pending / Incomplete Tasks + +- **DalRes10 WireGuard removal** — Howard doing it manually. When done, set **TermService → + Automatic** so RDP survives a reboot. +- **Tucson OpenVPN profile on ASUS-2024** — import the `98.225.73.165` `.ovpn` (split-tunnel) + alongside the Dallas one so Michelle can RDP DalRes10 offsite (connect the Tucson profile for + DalRes10, the Dallas profile for DALLAS). +- **Office WiFi** — ensure ASUS joins the UniFi "Goldstein" WiFi (10.1.10.x) at the office, not + `Gold-Scop` (Cox), for the VPN-off / Site Magic path. (Confirm exact SSID mapping.) +- **Billing** — #32384 was already Resolved/invoiced in June; new OpenVPN work not yet billed — + confirm with Mike whether to bill. +- **Remove machine-level WireGuard on ASUS-2024** (`WireGuardServer1-Client1`, inactive) for hygiene. + +## Reference Information + +- Syncro tickets: #32384 (112201728) remote access (Resolved); #32490 (113249206) Dallas RDP + (Invoiced, invoice 1650967814). +- Vault: `clients/goldstein/openvpn-remote-access.sops.yaml`; `services/unifi-site-manager`. +- Wiki: `wiki/clients/goldstein.md` (updated this session). +- UniFi consoles (ui.com): CGU-Goldstein Tucson / Dallas (owner). API key `services/unifi-site-manager`. +- OpenVPN Community MSI used: https://swupdate.openvpn.net/community/releases/OpenVPN-2.6.14-I001-amd64.msi +- Prior logs: `clients/goldstein/session-logs/2026-07/2026-07-06-…` + `…-07-07-…`.